# Non-production App Service Plans running higher tiers during off-hours Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/non-production-app-service-plans-running-higher-tiers-during-off-hours Azure App Service Plans define the compute resources allocated to web applications and are billed continuously based on their pricing tier - regardless... By: Stijn Depril [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) # Non-Production App Service Plans Running Higher Tiers During Off-Hours The short version Azure App Service Plans define the compute resources allocated to web applications and are billed continuously based on their pricing tier - regardless of whether the hosted apps are actively serving traffic. [Stijn Depril](https://www.linkedin.com/in/sdepril/) FinOps Architect @ Hi5 Consulting Azure service [Azure App Service](https://www.pointfive.co/efficiency-hub/cloud-services/azure-app-service) Category [Compute](https://www.pointfive.co/efficiency-hub/service-category/compute) Reference CER-0306 Type Inefficient Configuration ## Explanation Why the waste happens and who it affects. In non-production environments such as development, testing, or staging, workloads typically follow predictable usage patterns aligned with business hours. When these plans remain provisioned at higher-cost tiers around the clock, organizations pay premium rates for compute capacity that sits idle during evenings, weekends, and holidays. A common misconception is that stopping the apps within a plan will halt charges. In reality, the App Service Plan itself is the billing container, and charges accrue as long as the plan exists at a dedicated tier - even with all apps stopped or deleted. Simply stopping apps provides no cost relief. Instead, the plan's tier must be actively changed to a lower-cost option during periods of inactivity to realize savings. This temporal tier-switching pattern is distinct from scaling out (adjusting instance count) or right-sizing (choosing a permanently smaller tier), and is particularly effective for non-production workloads where brief interruptions during tier transitions are acceptable. Because higher tiers such as Premium or Standard carry significantly higher per-hour rates than Basic tier, leaving these plans unchanged during extended idle periods represents a significant and avoidable expense. Organizations with multiple non-production App Service Plans can accumulate substantial waste if this pattern is not addressed. ## Billing model The pricing dimensions that drive this cost. Azure App Service Plan billing is driven by two primary dimensions: Pricing tier (SKU) Each tier (Basic, Standard, Premium, PremiumV2, PremiumV3, PremiumV4) carries a different hourly rate, with higher tiers providing more CPU, memory, and platform capabilities at progressively higher cost. Number of VM instances Each instance in the plan is billed independently at the tier's rate, regardless of how many apps run on it or whether those apps are actively processing requests. Key billing behaviors that drive this inefficiency: - Charges accrue continuously as long as the plan is provisioned at a dedicated tier - stopping individual apps does not reduce cost. - The Free tier incurs no charge, and the Shared tier charges per-app based on CPU quota, but both lack features required for most workloads (e.g., custom SSL certificates, deployment slots). - Plans cannot be scaled to zero instances - the minimum is one instance in any dedicated tier. - Switching to a lower tier immediately reduces the per-instance hourly rate, making scheduled tier changes an effective lever for cost control during idle periods. ## How to detect 6 checks to find it in your estate. - Identify non-production App Service Plans (development, testing, staging, QA) running at Standard, Premium, or higher tiers continuously. - Review traffic and request patterns for App Service Plans to confirm whether usage is concentrated during business hours with extended idle periods overnight and on weekends. - Assess whether any non-production plans have scheduled tier-switching automation already in place, and flag those that do not. - Evaluate the cost differential between the current tier and the lowest tier that would still meet minimum off-hours requirements (e.g., preserving SSL certificate support requires at least Basic tier). - Confirm which features each plan depends on - such as deployment slots, autoscaling, or custom domains with TLS - and whether those features are needed during off-hours. - Review whether any external systems rely on the plan's outbound IP addresses, as these may change during tier transitions. ## How to fix 6 ways to remove the waste. - Implement scheduled automation to switch non-production App Service Plans from their higher daytime tier to a lower-cost tier (such as Basic) outside of business hours, and back again at the start of the working day. - Before enabling tier switching, inventory tier-dependent features in use - deployment slots require Standard or higher, and autoscaling requires Standard or higher - to ensure the target off-hours tier still meets minimum requirements. - If the plan runs a single instance, plan for brief downtime (typically seconds to minutes) during each tier change; for plans where even brief interruptions are undesirable, consider temporarily scaling out to multiple instances before the tier switch to allow rolling migration. - Verify that no external systems or firewall rules depend on the plan's outbound IP addresses, as these may change when switching between tier families. - Coordinate with application teams to confirm that off-hours downtime during tier transitions is acceptable for each environment before enabling automation. - Establish monitoring to verify that scheduled tier changes execute successfully and that plans are restored to the correct tier before business hours resume. ## Documentation Vendor references for pricing and configuration. - [Azure App Service Plans - Azure App Service learn.microsoft.com](https://learn.microsoft.com/en-us/azure/app-service/overview-hosting-plans) - [Manage an App Service Plan - Azure App Service learn.microsoft.com](https://learn.microsoft.com/en-us/azure/app-service/app-service-plan-manage) - [Plan and Manage Costs for App Service - Azure App Service learn.microsoft.com](https://learn.microsoft.com/en-us/azure/app-service/overview-manage-costs) - [App Service Pricing azure.microsoft.com](https://azure.microsoft.com/en-us/pricing/details/app-service/windows/) - [Reliability in Azure App Service learn.microsoft.com](https://learn.microsoft.com/en-us/azure/reliability/reliability-app-service) - [Azure App Service and cost optimization learn.microsoft.com](https://learn.microsoft.com/en-us/azure/well-architected/service-guides/azure-app-service/cost-optimization) ## Related inefficiencies [Browse the library](https://www.pointfive.co/efficiency-hub) - Azure App Service CER-0027 ### [Outdated Azure App Service Plan](https://www.pointfive.co/efficiency-hub/inefficiencies/outdated-azure-app-service-plan) Applications running on App Service V2 plans may incur higher operational costs and degraded performance compared to V3 plans. V2 uses older hardware generations that lack access to platform-level enhancements introduced in V3, including... Compute - Azure App Service CER-0157 ### [Idle Azure App Service Plan Without Deployed Applications](https://www.pointfive.co/efficiency-hub/inefficiencies/idle-azure-app-service-plan-without-deployed-applications) App Service Plans continue to incur charges even when no applications are deployed. This can occur when applications are deleted, migrated, or retired, but the associated App Service Plan remains active. Without ongoing workloads, these... Compute - Azure Virtual Machine Scale Sets CER-0314 ### [Fixed Instance Count on Virtual Machine Scale Set Without Autoscaling](https://www.pointfive.co/efficiency-hub/inefficiencies/fixed-instance-count-on-virtual-machine-scale-set-without-autoscaling) Azure Virtual Machine Scale Sets can operate in two modes: manual scaling with a fixed instance count, or autoscaling with dynamic instance counts that respond to demand. When a scale set is configured with manual scaling, it maintains the... Compute --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.