Delete empty App Service plans

This is the cleanest saving in the Azure catalogue. An empty paid App Service plan is a fixed, recurring charge against your bill for which you receive nothing. Deleting it removes that line item in full from the next billing cycle onwards, and there is no offsetting cost: you are not buying a smaller plan, not paying a migration fee, not adding a service. The plan simply stops, and the spend stops with it.

The saving is the plan's tier and instance count multiplied by the hours in a month. An empty Standard plan reserving a single instance is, by community and Microsoft documentation, on the order of tens of dollars a month each; a Premium plan or one reserving several instances is multiples of that. Across an estate that has accumulated retired apps over a couple of years, the empty plans are rarely just one. The right framing for the finance pack is a list of empty paid plans with each one's monthly run rate, summed: that figure is the annualised saving available from a single afternoon's work.

Treat the saving as risk-free where the plan is genuinely empty, and as a small, named judgement call only where someone believes the plan is being kept warm for a future app. The cost of keeping an empty plan 'just in case' is the full monthly charge for every month it waits, against a recreation cost that is minutes of redeployment when the app actually arrives.

Priya is the finance partner on the half-year review. The Azure Advisor cost recommendations include several unused App Service plans, and the instinct is to ask one question before anything else: what is each one actually costing per month? She asks the platform team to pair every empty plan with its tier and instance count, because that is the run rate. The list comes back with two empty Standard plans each reserving a single instance, and one empty PremiumV3 plan reserving two instances left over from a proof of concept that wrapped up last year.

Priya puts a monthly figure against each from the App Service price list, sums them, and annualises. The PremiumV3 plan alone dwarfs the two Standard plans combined, which immediately reorders the work: delete the Premium one today. The finance pack reads plainly: 'Three empty paid plans are billing for compute that runs nothing. Deleting them removes the charge in full from next cycle, with no offsetting cost and no service lost. Annualised saving attached. The only judgement call is whether the team genuinely intends to redeploy onto any of them soon, in which case the carrying cost of waiting is the full monthly charge against a few minutes of recreation later.'

The cost case here is unusually clean because there is no trade-off to weigh. Most savings ask you to accept something in return: a smaller instance with less headroom, a reserved-capacity commitment that locks you in, a tier with fewer features. Deleting an empty plan asks for none of that. The plan hosts nothing, so removing it costs nothing in capability and saves its full run rate from the next cycle onwards.

Quantify it the obvious way: tier multiplied by instance count multiplied by the hours in a month, per empty plan, summed across the estate. Microsoft and the community document empty paid plans as a recurring charge worth tens of dollars a month for a single Standard instance and considerably more for Premium or multi-instance plans, so a handful of forgotten plans is a four-figure annual line. The finance role is to attach that run rate to each plan so the work is prioritised highest-cost-first and the saving is booked as recurring, not one-off.

Some cost optimisations are trade-offs: you accept a little less performance or resilience for a lower bill, and someone has to weigh that. Deleting an empty App Service plan is not one of those. The plan hosts no apps, serves no traffic and delivers no value, yet it bills every hour. Removing it lowers the bill and removes nothing anyone is using.

The leadership question is not 'should we cut this?' It is 'why is it still running, and how many more like it are there?' Empty plans accumulate quietly as apps are retired and the compute beneath them is left behind. They are a small, steady leak rather than a single large number, which is exactly why they survive: no one owns the bill line, so no one switches it off.

The decision worth making is not about any single plan. It is to treat 'empty paid plan' as a standing waste category that gets found and cleared on a cadence, so the leak is closed by routine rather than rediscovered every time someone reads the bill closely.

At a cost review the CFO pointed at a steady App Service line that had not moved in months and asked the obvious question: are we using all of that? The honest answer at the time was that nobody was certain, because the plans had accumulated as apps were retired and no single person owned the compute left behind. Some of it was almost certainly serving live traffic. Some of it, equally certainly, was not.

The team's response was to stop treating it as a one-off cleanup and start treating empty paid plans as a standing waste category. They ran the query that pairs every plan with its real app count, deleted the ones that were empty and on a paid tier, and then put that same query on a monthly cadence so a plan can never sit empty and billing for long again. The next time the CFO asked, the answer had changed from 'we think most of it is in use' to 'every paid plan has an app on it, and we check monthly.' That shift, from rediscovering the leak each time someone reads the bill to closing it on a routine, is the durable win here, and it costs nothing to maintain.

Nearly every estate that has run App Service for a couple of years carries empty paid plans, for the same reason: apps get retired faster than the compute beneath them gets cleaned up, and nobody owns the leftover. The charge is too small to alarm and too quiet to notice, which is precisely why it persists. It is the definition of avoidable, ongoing waste.

The cost of clearing it is minutes of work and zero capability lost, while the cost of ignoring it is the full monthly charge for every empty plan, every month, indefinitely. This is the rare class of saving where there is genuinely nothing on the other side of the ledger, which is exactly why it should be handled by routine rather than left to be rediscovered.