Azure App Service Plan
Does ZopNight manage Azure App Service Plan?
An App Service plan bills continuously by SKU and instance count regardless of traffic; even a plan hosting 0 apps pays its full rate. ZopNight maps every plan to its hosted apps via Resource Graph, reads 60 days of utilization, and flags empty and oversized plans for downgrade or deletion.
Rules that fire on Azure App Service Plan
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost visibility only; apps on the plan (Function Apps) are scheduled individually. |
App Service plans provide the reserved compute that Web Apps and Function Apps run on, billed continuously by SKU regardless of traffic. Empty plans (plans hosting zero apps) are pure waste, and oversized plans are close behind.
The plan is the meter; the apps are tenants
Web Apps and Function Apps do not bill. Their plan does. A plan charges by its SKU tier and instance count for every hour it exists, indifferent to traffic, deployments, or whether any app is running on it at all. Stopping every app on a plan changes the invoice by nothing. This inversion is the single most misunderstood fact in App Service economics, and it is why an environment can look “all stopped” in the portal while its compute bill continues untouched.
Empty and oversized plans ZopNight flags
Azure Resource Graph discovery captures each plan’s SKU, instance count, and hosted-app relationships, so the empty-plan case, a plan whose app count is zero, falls out of the data immediately. Utilization from a 60-day Azure Monitor lookback identifies the subtler case: plans running a Premium tier and multiple instances for workloads that would fit a size or two down. Cost Management attributes actual spend per plan, turning both findings into ranked savings.
Why the plan itself is not scheduled
The plan carries no stop operation, so it is discovery and cost visibility in ZopNight; the apps riding on it, Function Apps in particular, are scheduled individually. The practical consequence: a plan’s saving arrives through rightsizing (dropping tier or instance count), consolidation (packing apps from several half-empty plans into one), or deletion of plans left hosting nothing.
How plans end up burning money
Deployment tooling that creates a fresh plan per app until dozens run at low occupancy; the last app on a plan being deleted while the plan survives; and instance counts scaled up for a launch and never walked back.
App Service plans in the portal
Azure portal → App Service plans lists every plan with SKU, instance count, and an Apps column. Sort by that column and start the audit at zero.