Idle App Service plans.

Someone moved the API to a new plan during a migration, or deleted the app from a pipeline, and the plan it ran on is still there: same tier, same instance count, same line on the invoice. Nobody opens a plan with no apps in it, so nobody notices.

These are the six questions that come up every time we walk a team through this, answered with what Microsoft's docs actually say.

01We deleted the app. Why is the plan still billing?

Because the plan is what you pay for, not the app. In the dedicated tiers (Basic, Standard, Premium v2/v3/v4) the plan defines the number of VM instances and each instance is charged, whatever runs on it. Microsoft is explicit about the empty case: plans with no apps still incur charges, because they keep reserving the configured instances.

There is a safety net, and it's narrow. When you delete the last app in a plan, App Service deletes the plan too, by default. It doesn't fire when the app moved: the Change plan flow only targets plans in the same resource group, region and OS, so migrations and re-platforming usually mean a new plan somewhere else, and the old one is left holding nothing.

02If we stop the app, does the charge stop?

No. The meter is an hourly rate per instance, prorated to the second, for as long as the instance is allocated. Stopping an app doesn't change the plan's instance count, so it doesn't change the bill. This is the App Service version of a VM that was shut down from inside the OS: it looks off, and it's still allocated. If a plan hosts three stopped apps and nothing else, it's billing exactly what it billed when they were busy.

03Can we keep the plan without paying for it?

Yes: scale it to Free (F1). Microsoft's own advice for a plan you want to keep after the last app is gone is to delete it or scale it down to Free. Free is the only tier with no compute charge. Two catches if apps are still in it: a downgrade can be refused for features the lower tier doesn't have (Microsoft's example is an SNI TLS binding that isn't allowed in the target compute mode), and slots, below, set a floor.

04Do deployment slots cost extra?

Not directly. There's no extra charge for slots. They cost you in two quieter ways. They run on the plan's instances, and an active slot counts as an active app competing for the same CPU and memory, so a staging slot nobody swapped in a year still pushes the plan towards a bigger size. And slots need Standard or higher, with a cap per tier: an app with more than five slots can't be scaled down to Standard. A forgotten slot is a floor under the tier.

05Our plan is Premium v3 with two small apps. Is that over-provisioned?

Probably. Microsoft's density guidance puts a P1v3 at 16 apps and a P3v3 at 64 before you should isolate one. Two apps on a P3v3 is usually a size someone picked for a launch and never revisited. Azure Advisor has a Right-size underutilized App Service plans recommendation based on 7 days of low CPU. Treat it as a lead, not a verdict: a week can miss a month-end peak.

Look at the instance count before the tier. Scale-out is where the money goes: each instance is billed, and autoscale on Standard and up exists so you only pay for the instances you need. A plan pinned at three instances since go-live is three times the bill of a plan that scales in at night. One more trap if you hold Premium v3 reservations: if you run fewer instances than you reserved, you still pay for the reservation.

06How do we find every empty plan, across every subscription?

The plan resource carries numberOfSites, the number of apps assigned to it. One Resource Graph query covers every subscription you can read:

Resources
| where type =~ 'microsoft.web/serverfarms'
| where toint(properties.numberOfSites) == 0
| project name, resourceGroup, subscriptionId, sku = tostring(sku.name)

Filter out the F1 rows: they cost nothing. Advisor also has a preview recommendation for this, Unused or empty App Service plan. Before you delete, check what the plan pulled in around it. Microsoft lists the things that keep accruing after App Service resources are gone: storage accounts for backups and logs, Log Analytics workspaces, Key Vaults holding certificates, and reservations that haven't expired. Those are the same leftovers we covered in orphaned Azure resources, and the test environment that hosted the app is usually the one in dev/test resources left running.

GraphPaaS runs that query for you, in every tenant you manage. The Azure view of Bills lists idle resources across every enabled subscription, with empty App Service plans next to stopped VMs, unattached disks and Advisor's own cost recommendations, each with what it billed in the last 30 days, most expensive first.