05 - Verify Deployments

Visual Flow

Flow Explanation

When you deploy an Azure Container App, it is not just a single black-box container. Traffic hits the Ingress Gateway, which routes it to the Active Revision (your specific version blueprint). That revision spins up Replicas (the actual running instances).

As this happens, telemetry is split into two distinct streams: System Logs capture infrastructure events (like Azure pulling your image), while Console Logs capture the actual code output (like Python exceptions) generated by the Replicas.

Overview: The Black Box Problem

Pushing code to the cloud is easy. Figuring out why it crashed is hard.

Verification bridges the gap between deployment intent (what you wanted to happen) and production reality (what is actually running). If an AI service fails to start, it could be a bad API key, an inaccessible private registry, or a pure code syntax error.

To debug effectively, you must understand the Container App hierarchy and verify state from the top down.

1. The App Level (Confirming Configuration)

Before you dig into deep logs, you need to check the front door. Did you accidentally configure your network to be internal when it needs to be public? What is the actual URL you should be hitting?

Why: You run this to get the macro-level state of the app, grab the Fully Qualified Domain Name (FQDN) to test connectivity, and confirm your ingress settings are correct.

az containerapp show \
  -n ai-api \
  -g rg-aca-demo

2. Revisions (The Blueprints)

A revision is an immutable snapshot of your container app. Every time you change an environment variable, update a container image, or swap a secret, ACA creates a new revision. This is what enables safe rollouts and zero-downtime deployments.

Why: You run this command to verify that Azure actually created a new revision for your latest update, and to confirm whether it successfully reached a healthy Active state.

az containerapp revision list \
  -n ai-api \
  -g rg-aca-demo

If you need to dig into the past to see older blueprints, append --all.

3. Replicas (The Workers)

Revisions are just blueprints; Replicas are the actual running containers doing the heavy lifting. In request-driven workloads like AI inference, replica behavior dictates your performance. If traffic spikes, ACA scales from 1 replica to 10. If traffic drops, it scales to zero.

Why: You check replicas to see if your app is suffering from "cold starts" (scaling from zero takes time), or to catch instances that are stuck continuously crashing and restarting.

az containerapp replica list \
  -n ai-api \
  -g rg-aca-demo

If you need to look at replicas for an older specific version, you can append --revision MyRevisionName.

4. The Dual-System Logs

When the app is broken, logs are your source of truth. Container Apps intentionally separates logs into two streams so infrastructure noise doesn't bury your application errors.

Console Logs (App Code)

This stream captures standard output (stdout) and standard error (stderr) generated by your code. If your Python script throws an exception or your Node.js app logs a 500 error, it goes here.

Why: You run this to see exactly what your application code is thinking. The --follow flag streams the logs live in your terminal, and --tail 30 ensures you only see the most recent events.

az containerapp logs show \
  -n ai-api \
  -g rg-aca-demo \
  --follow \
  --tail 30

System Logs (Infrastructure)

Sometimes your code is flawless, but the Azure platform failed. System logs show you what the Azure orchestration layer is doing.

Why: You query system logs to catch infrastructure failures like "Image Pull Authentication Denied", out-of-memory container kills, or network routing issues.

az containerapp logs show \
  -n ai-api \
  -g rg-aca-demo \
  --type system

Debugging and Validation

Verification requires knowing what to look for when things break.

Gotcha: The endless crash loop (CrashLoopBackOff)

• Symptom: You deploy a new version. The revision says active, but when you hit the URL, you get an HTTP 502 Bad Gateway.
• Why it happened: Your container code is throwing a fatal error immediately upon boot (e.g., a missing environment variable). The Azure platform detects the crash, tries to restart the replica, and it crashes again. It gets stuck in a loop.
• The Fix: Stop guessing and check the logs. Run the replica list command to confirm the replica is in a crash state, then run logs show to read the exact stack trace your code spit out before it died. Fix the code or inject the missing variable, and deploy again.

Strategic Best Practices

• Start with logs: Always use az containerapp logs show first to capture immediate startup and runtime errors.
• Use revisions for rollout validation: Never assume a deployment worked. List revisions after an update to explicitly confirm the new revision exists and is active.
• Inspect replicas during incidents: Check replicas to detect scale-to-zero latency issues, crash loops, or unbalanced traffic routing.