Submit feedback on
Non-Production App Service Plans Running Higher Tiers During Off-Hours
We've received your feedback.
Thanks for reaching out!
Oops! Something went wrong while submitting the form.
Close
Non-Production App Service Plans Running Higher Tiers During Off-Hours
Stijn Depril
CER:

CER-0306

Service Category
Compute
Cloud Provider
Azure
Service Name
Azure App Service
Inefficiency Type
Inefficient Configuration
Explanation

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. 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.

Relevant Billing Model

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.
Detection
  • 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.
Remediation
  • 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.
Submit Feedback