By Cloudledger · Updated
You pay for the plan, not the app
App Service billing is generally driven by the App Service plan: its pricing tier, instance size and instance count, charged while the plan exists rather than only while the app receives traffic. Several apps can share one plan, and an empty plan can still cost money.
Find plans with little or no traffic
Review each plan’s apps, instance count and request volume together. Non-production plans left on production-grade tiers are a common finding, as are plans left behind after an app was retired or migrated elsewhere. Because the plan bills whether or not the app receives requests, an empty plan is pure overhead — but check for scheduled jobs, webhooks and background workers before calling one idle.
- List App Service plans with tier, size and instance count.
- Map apps and deployment slots to each plan.
- Compare request volume and CPU/memory usage per plan.
- Identify plans with no active apps or negligible traffic.
Slots and scaling change the shape
Deployment slots generally run on the same plan and consume its capacity. Autoscale rules can raise instance counts during peaks and keep them high if the rules are not tuned. Review scale-in behaviour as carefully as scale-out.
Supporting services belong in the total
Application Insights ingestion, storage, custom domains, certificates, networking features and databases contribute to the real cost of running a web application. Compare the full picture before concluding a tier change will deliver the expected saving.
Change with a rollback plan
Lower tiers can remove features such as staging slots, scaling limits or networking options. Confirm the app does not depend on them, test where possible, and verify both performance and the next complete billing period after the change.