Container Apps keeping replicas warm with zero requests
What does ZopNight detect here?
ZopNight flags an Azure Container App that ran replicas, a `Replicas` average above zero, while its `Requests` metric stayed at zero on average and at peak, with at least 7 days of request data. The minimum replica count kept compute billing for an app nobody called. Apps that already scale to zero are left alone, since they cost almost nothing.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-273 |
| Category | idle |
| Severity | medium |
| Metric | Replicas, Requests |
| Threshold | Requests = 0 (average and peak), Replicas average > 0 |
| Evaluation window | 30d |
| Source | ZopNight |
| Permissions used | Microsoft.App/containerApps/read · Microsoft.Insights/Metrics/Read |
Where it applies
Why a warm replica with no traffic still costs money
In the Consumption plan, Azure Container Apps charges each replica for the resources it consumes. Microsoft’s billing guide explains that a replica can drop to a reduced idle rate, but only when the revision has a minimum replica count above zero, is scaled to that minimum, and the replica is running, handling no HTTP requests, using under 0.01 vCPU and receiving under 1,000 bytes per second. Idle is cheaper than active, but it is not free.
The default minimum is 0 replicas, per the scaling reference, and Microsoft states that a revision scaled to zero replicas incurs no resource consumption charges. The waste this rule looks for comes from a minimum raised above zero, often for cold-start reasons, on an app that turned out to get no calls.
Checking replicas and requests on an app
az containerapp show --resource-group my-rg --name my-app \ --query "{min:properties.template.scale.minReplicas, max:properties.template.scale.maxReplicas}"
az monitor metrics list --resource <container-app-resource-id> \ --metric Replicas Requests --offset 30d --interval PT24H --aggregation Average MaximumReplicas running, requests absent
- The
Requestsseries is present and is zero on both average and peak. - The
Replicasseries is present and its average is above zero. This separates a warm, idle app from one that has correctly scaled to nothing. - The request series covers at least 7 days, so a new app with a warm replica and no traffic yet is not told to delete itself in its first hours.
- The app has a known monthly cost above zero.
Apps that are not flagged
An app with zero replicas, or with no replica data at all, is skipped: scaling to zero is the healthy state and the safe assumption. Any request, even one peak, clears the app. Missing request data or less than 7 days of it also means no finding.
Saving is the compute the replicas used
saving = current monthly compute cost of the Container Appcost after fix = 0 (scaled to zero or deleted)Letting the app scale to zero, or removing it
- Check the revision traffic split and ingress settings; a misconfigured ingress can hide real traffic from the app.
- If the app should stay available, let it scale to zero:
az containerapp update --resource-group my-rg --name my-app --min-replicas 0. Expect the first request after a quiet period to take longer while a replica starts. - If nothing needs it, delete it with
az containerapp delete --resource-group my-rg --name my-app --yes.