Revision Provisioning Failure¶

1. Summary¶

Symptom¶

A new revision is created but never progresses to a healthy, active state. Typical signs are healthState=Failed, deployment commands that return success while no healthy replicas appear, and system logs that show validation, secret, probe, or template errors.

Why this scenario is confusing¶

Control-plane success is easy to misread as workload success. A deployment command can succeed while the new revision still fails during provisioning because of invalid template settings, unresolved secrets, or startup and probe mismatches.

Troubleshooting decision flow¶

flowchart TD
    A[Revision health is Failed] --> B{Error references secret or env?}
    B -->|Yes| C[Fix secret names and env secretRef mapping]
    B -->|No| D{Probe or startup timeout in logs?}
    D -->|Yes| E[Adjust startup and readiness probe settings]
    D -->|No| F[Validate command, resources, and template fields]
    C --> G[Deploy new revision and verify health]
    E --> G
    F --> G

2. Common Misreadings¶

• "Deployment succeeded, so runtime must be fine." Control-plane acceptance does not guarantee runtime readiness.
• "It is always image pull." Provisioning can fail due to invalid template or missing secret reference.

3. Competing Hypotheses¶

4. What to Check First¶

Metrics¶

• Revision failure count and failed deployment events in the Container App overview.

Logs¶

let AppName = "ca-myapp";
ContainerAppSystemLogs_CL
| where ContainerAppName_s == AppName
| where Log_s has_any ("Failed", "provision", "secret", "probe", "invalid")
| project TimeGenerated, RevisionName_s, Reason_s, Log_s
| order by TimeGenerated desc

Platform Signals¶

az containerapp revision list --name "$APP_NAME" --resource-group "$RG" --output table
az containerapp show --name "$APP_NAME" --resource-group "$RG" --query "properties.template" --output json
az containerapp secret list --name "$APP_NAME" --resource-group "$RG"

5. Evidence to Collect¶

Required Evidence¶

Useful Context¶

• Whether the failure started after a template or secret change.
• Whether an older revision with the same image is healthy.
• Whether startup behavior changed enough to require different probe timing.

Observed healthy revision lifecycle (use as comparison timeline):

ContainerAppUpdate  → Updating containerApp: ca-myapp
RevisionCreation    → Creating new revision
ContainerCreated    → Created container 'ca-myapp'
ContainerStarted    → Started container 'ca-myapp'
RevisionReady       → Revision ready
ContainerAppReady   → Running state reached

6. Validation and Disproof by Hypothesis¶

H1: Invalid template settings¶

Signals that support:

• Revision fails immediately.
• No long startup timeline appears.
• System logs show invalid or other template-related failures.
• Full template output contains suspect command, resource, or container fields.

Signals that weaken:

• Same template works in another revision.
• Logs show the container starts and then fails later instead of failing during provisioning validation.

What to verify:

az containerapp revision list --name "$APP_NAME" --resource-group "$RG" --output table
az containerapp show --name "$APP_NAME" --resource-group "$RG" --query "properties.template" --output json
az containerapp logs show --name "$APP_NAME" --resource-group "$RG" --type system
az containerapp show --name "$APP_NAME" --resource-group "$RG" --query "properties.template.containers[0].resources" --output json

Disproof logic:

If the template matches a known-good revision and logs instead show later-stage probe or startup issues, template invalidity is less likely.

H2: Missing or mismatched secret reference¶

Signals that support:

• Errors mention secretRef or env unresolved.
• Secret inventory does not contain a referenced secret.
• Environment mapping points to a missing or wrong secret name.

Signals that weaken:

• All referenced secrets resolve correctly.
• System logs do not mention secret resolution problems.

What to verify:

az containerapp secret list --name "$APP_NAME" --resource-group "$RG"
az containerapp show --name "$APP_NAME" --resource-group "$RG" --query "properties.template.containers[0].env" --output json
az containerapp logs show --name "$APP_NAME" --resource-group "$RG" --type system

Disproof logic:

If every secretRef maps cleanly to an existing secret and system logs do not mention secret failures, this hypothesis is weakened.

H3: Probe/startup mismatch¶

Signals that support:

• Health probe failures occur before the app is ready.
• System logs show probe-related failures.
• The container starts but never reaches RevisionReady.

Signals that weaken:

• No probe errors in system logs.
• The app becomes ready when tested with relaxed startup timing.

What to verify:

az containerapp logs show --name "$APP_NAME" --resource-group "$RG" --type system
az containerapp show --name "$APP_NAME" --resource-group "$RG" --query "properties.template.containers[0].probes" --output json

let AppName = "ca-myapp";
ContainerAppSystemLogs_CL
| where ContainerAppName_s == AppName
| where Log_s has_any ("Failed", "provision", "secret", "probe", "invalid")
| project TimeGenerated, RevisionName_s, Reason_s, Log_s
| order by TimeGenerated desc

Disproof logic:

If no probe failures appear and the container never even reaches the probe stage, startup timing is not the main cause.

7. Likely Root Cause Patterns¶

8. Immediate Mitigations¶

1. Validate secret names and ensure every secretRef exists.
2. Confirm resource requests/limits and probe settings are realistic for startup behavior.
3. Fix any invalid template fields and deploy a new revision.
4. Confirm the new revision becomes active and healthy.

9. Prevention¶

• Enforce template validation checks in CI.
• Keep a known-good baseline revision for rollback.
• Standardize probes and env naming conventions across services.

See Also¶

• Probe Failure and Slow Start
• Secret and Key Vault Reference Failure
• Revision Failures and Startup KQL

Sources¶

• Revisions in Azure Container Apps
• Health probes in Azure Container Apps
• Troubleshoot Azure Container Apps