Min Replicas Cost Surprise¶

Symptom¶

There is no runtime failure, but Azure Cost Management shows continuous spend during quiet periods. The app appears idle, yet charges continue because at least one replica or one dedicated node stays allocated.

flowchart TD
    A[App receives little or no traffic] --> B[Scale settings still enforce baseline capacity]
    B --> C{minReplicas equals 0?}
    C -->|Yes| D[Revision can scale to zero]
    C -->|No| E[Replica stays allocated]
    E --> F[Consumption idle cost or dedicated baseline remains]
    D --> G[No runtime cost during zero-replica periods]
    F --> H[Unexpected bill prompts investigation]

Possible Causes¶

minReplicas is set to 1 or higher on a workload that is idle for long periods.
Multiple active revisions each keep a baseline replica.
The app runs in a dedicated workload profile, so node cost remains even when traffic is light.
A performance optimization kept replicas warm without documenting the ongoing cost trade-off.

Diagnosis Steps¶

Inspect the app scale configuration:

az containerapp show \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --query "properties.template.scale" \
    --output json

Command	Purpose
`az containerapp show --name "$APP_NAME" --resource-group "$RG" --query "properties.template.scale" --output json`	Reads the Container App resource and extracts the full scale configuration in structured form for operator review, which is the specific surface this troubleshooting step needs to confirm.

Check whether more than one active revision is holding replicas:

az containerapp revision list \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --query "[].{name:name,active:properties.active,replicas:properties.replicas}"

Command	Purpose
`az containerapp revision list --name "$APP_NAME" --resource-group "$RG" --query "[].{name:name,active:properties.active,replicas:properties.replicas}"`	Lists every revision with its active flag and replica count so you can see whether cost is coming from multiple active revisions staying warm.

Review the replica metric during an idle window:

az monitor metrics list \
    --resource "/subscriptions/<subscription-id>/resourceGroups/$RG/providers/Microsoft.App/containerApps/$APP_NAME" \
    --metric Replicas \
    --aggregation Average \
    --timespan P1D

Command	Why it is used
`az containerapp show --query "properties.template.scale"`	Confirms whether `minReplicas` is intentionally keeping replicas alive.
`az containerapp revision list --query "[].{name:name,active:properties.active,replicas:properties.replicas}"`	Finds revision sprawl that can multiply baseline cost.
`az monitor metrics list --metric Replicas --aggregation Average --timespan P1D`	Verifies that replicas remained present even during low-traffic periods.

If the environment uses dedicated workload profiles, check whether the issue is actually reserved node cost instead of app-level runtime cost.

Resolution¶

Set minReplicas to 0 for workloads that can tolerate cold starts:

az containerapp update \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --min-replicas 0 \
    --max-replicas 3

Keep minReplicas above zero intentionally only when latency, cache warmness, or queue pickup time justifies the baseline spend.
Reduce active revisions if old revisions are still holding warm replicas.
Right-size dedicated profiles when the real cost driver is reserved dedicated capacity rather than minReplicas itself.

Command	Why it is used
`az containerapp update --min-replicas 0 --max-replicas 3`	Removes the always-on replica baseline for workloads that can scale to zero.

Prevention¶

Treat minReplicas as a cost decision, not only a performance setting.
Document which apps are allowed to scale to zero and which must stay warm.
Review idle replica metrics during monthly cost reviews.
When using dedicated workload profiles, separate app-level replica tuning from environment-level node reservation decisions.