A revision is a versioned snapshot of an Azure Container App after a change such as a new image, environment variable, scale setting, or template configuration. The old revision can stay inactive, keep serving traffic, or be replaced depending on revision mode. This gives teams a practical way to roll out, test, roll back, or compare container app versions. Think of it as the deployable history of a container app, including the settings that make that version run.
A revision is a versioned snapshot of an Azure Container App after a change such as a new image, environment variable, scale setting, or template configuration. The old revision can stay inactive, keep serving traffic, or be replaced depending on revision mode. This gives teams a practical way to roll out, test, roll back, or compare container app versions. Think of it as the deployable history of a container app, including the settings that make that version run.
In Azure architecture, revisions belong to Azure Container Apps and sit between deployment automation, ingress traffic, scaling, observability, and application runtime configuration. A revision has provisioning and running states, can contain replicas, can receive traffic through the app URL or labels, and can be activated or deactivated. Revision-scope changes create new revisions; application-scope settings may not. Operators inspect revisions with Azure CLI, portal revision management, logs, traffic weights, labels, probes, and container app diagnostics during release and rollback work.
Why it matters
Revisions matter because container releases fail in very specific ways: a bad image starts, probes fail, CPU limits are wrong, secrets were rotated, or a new feature needs a controlled rollout. Without revision awareness, teams see only “the app is broken” and miss which version, replica, or configuration caused it. With revisions, operators can keep the old version serving traffic while the new revision becomes ready, inspect failed running states, move labels, deactivate bad versions, and copy a known-good revision for recovery. The result is safer releases, clearer incident timelines, and less guesswork when production traffic meets new code. quickly.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In the Container Apps Revision management page, you see active and inactive revisions, traffic percentages, labels, running states, replica counts, and revision-specific URLs. during rollouts.
Signal 02
In Azure CLI output, az containerapp revision list or show exposes revision names, provisioning state, running state, creation time, image, and traffic details. in incidents.
Signal 03
In release pipelines and incident notes, the revision suffix, image digest, traffic weight, and logs identify exactly which container app version caused or fixed behavior.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Roll back a bad Container Apps deployment by reactivating or routing traffic back to the last known-good revision.
Diagnose why a new image is stuck in activating, degraded, or failed state before production traffic moves.
Restart active revisions after secret changes so replicas pick up updated values without rebuilding the app.
Copy a stable revision and adjust CPU, memory, or scale settings for a controlled performance experiment.
Use revision labels and URLs to test a candidate build before exposing it through the main application endpoint.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Food delivery API catches a failing checkout release
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A food delivery platform deployed a new checkout container to Azure Container Apps. Orders slowed within minutes, but the app-level dashboard hid which version introduced the problem.
🎯Business/Technical Objectives
Identify the exact revision tied to checkout latency.
Keep the previous version serving traffic during investigation.
Rollback without rebuilding the container image.
Add pipeline checks that fail before full traffic cutover.
✅Solution Using Revision
The operations team used Revision data as the incident anchor. Azure CLI listed active revisions, showed the new revision’s image tag, and confirmed it had a degraded running state after readiness probes began timing out. Logs scoped to the revision showed a new payment dependency retry loop. Because the previous revision still had healthy replicas, traffic was moved back to it and the bad revision was deactivated after evidence was captured. The release pipeline was updated to wait for revision readiness, compare p95 latency by revision, and record the revision suffix in deployment notes.
📈Results & Business Impact
Checkout p95 latency returned from 4.9 seconds to 620 milliseconds in 12 minutes.
Rollback avoided an estimated $180,000 in failed lunch-hour orders.
Pipeline readiness checks caught two similar failures before production the next month.
Incident notes tied logs, image tag, and traffic movement to one revision name.
💡Key Takeaway for Glossary Readers
A revision gives teams the exact version boundary needed for fast Container Apps rollback.
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A gaming studio needed to tune an event-processing API before a seasonal launch. Developers wanted higher CPU and memory, but operations needed proof before changing production sizing.
🎯Business/Technical Objectives
Test a resource-adjusted service version without replacing the stable revision.
Measure latency and errors by revision under controlled traffic.
Keep rollback immediate during the launch rehearsal.
Avoid overprovisioning if the resource change did not help.
✅Solution Using Revision
The platform team used Revision copy to create a new revision from the stable event-service version, changing CPU and memory while keeping the same image. In multiple revision mode, they routed a small percentage of rehearsal traffic to the candidate revision and watched replica count, CPU, memory, errors, and p95 latency separately. Azure CLI captured revision show output, traffic weights, and labels before each test step. When the tuned revision performed better, the label was moved to support final validation, and the old revision stayed active until launch signoff.
📈Results & Business Impact
Candidate revision reduced p95 event latency from 840 milliseconds to 390 milliseconds.
Error rate stayed below 0.2 percent during rehearsal traffic splitting.
The team avoided a blanket workload-profile upgrade worth about $9,000 monthly.
Rollback remained a single traffic-weight command throughout testing.
💡Key Takeaway for Glossary Readers
Revisions make performance experiments safer because each runtime version can be measured and reversed separately.
Case study 03
Nonprofit restarts donation portal after secret rotation
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A nonprofit rotated payment provider credentials for its donation portal. The Container App remained online, but some replicas continued using the old secret and caused intermittent payment failures.
🎯Business/Technical Objectives
Refresh active runtime configuration without deploying a new image.
Find which revision still served payment traffic.
Reduce failed donations during the annual fundraiser.
Create a repeatable secret-rotation runbook.
✅Solution Using Revision
The cloud team treated the active Revision as the operational target. They listed revisions, confirmed the production revision and traffic share, then restarted the active revision after the secret update so replicas reloaded the current secret values. Logs scoped to that revision confirmed the old credential error disappeared. The team did not build a new container image because the code had not changed. The runbook now includes CLI checks for active revision, traffic weight, restart command, payment health probe, and post-rotation transaction sampling. Finance leaders received a confirmation timeline.
📈Results & Business Impact
Payment authorization failures dropped from 6.4 percent to 0.4 percent within 20 minutes.
The nonprofit preserved an estimated $72,000 in fundraiser donations.
Secret-rotation time fell from 90 minutes to 18 minutes in the next exercise.
Operators gained a clean distinction between secret refresh and application redeploy.
💡Key Takeaway for Glossary Readers
Revision operations are not only for code releases; they also control running replicas after configuration-sensitive changes.
Why use Azure CLI for this?
For Container Apps revisions, Azure CLI is one of the fastest ways to get beyond portal screenshots. I use it to list revisions, show the exact revision configuration, inspect running and provisioning states, restart a revision after secret updates, deactivate a bad revision, and export traffic information during incidents. In production, naming and timing matter; CLI output gives revision names, image tags, timestamps, replica status, and FQDN details that fit into release notes and incident timelines. It also makes rollout checks repeatable in pipelines, where waiting for readiness is safer than assuming the portal refreshed correctly. during every deployment. safely.
CLI use cases
List active and inactive revisions for a container app before starting a release or rollback.
Show a revision to inspect image, state, labels, traffic, replica health, and creation metadata.
Restart a revision after secret changes or transient runtime failure without changing the image.
Deactivate a failed or obsolete revision after confirming traffic and rollback requirements.
Copy a known revision to create a controlled variant with different resources or environment variables.
Do not deactivate or restart a production revision until rollback, user impact, and active traffic have been reviewed.
What output tells you
Revision list output shows which versions are active, inactive, receiving traffic, labeled, or available for rollback.
Revision show output explains provisioning and running states, image details, replica health, and timestamps.
Traffic and label output proves whether users are reaching the intended revision or an older deployment.
Log output tied to a revision separates new-code failures from platform, scaling, or dependency problems.
Mapped Azure CLI commands
Revision Azure CLI commands
operational
az containerapp revision list --name <container-app> --resource-group <resource-group> -o table
az containerapp revisiondiscoverContainers
az containerapp revision show --name <container-app> --revision <revision-name> --resource-group <resource-group>
az containerapp revisiondiscoverContainers
az containerapp revision restart --revision <revision-name> --resource-group <resource-group>
az containerapp revisionoperateContainers
az containerapp revision deactivate --revision <revision-name> --resource-group <resource-group>
az containerapp revisionoperateContainers
az containerapp revision copy --name <container-app> --resource-group <resource-group> --revision <revision-name>
az containerapp revisionoperateContainers
Architecture context
Architecturally, a revision is the unit that makes Azure Container Apps releases observable and reversible. The container app is the stable service identity, while revisions represent concrete runtime versions under that service. In single revision mode, the platform switches traffic after readiness criteria are met. In multiple revision mode, traffic weights and labels let teams test, canary, or blue-green selected revisions. Architects should decide how many inactive revisions to keep, whether labels are part of release design, how health probes gate rollout, how secrets are refreshed, and how logs are correlated by revision during incidents. across release environments. and incidents.
Security
Security impact is practical and direct. A revision can contain a specific image digest, environment variables, secret references, managed identity usage, ingress exposure, and runtime configuration. If a vulnerable image or misconfigured environment variable ships, the revision becomes the evidence and rollback target. Secrets are not automatically re-read by running replicas in every case; active revisions may need restart after secret changes. Operators should restrict who can create, copy, activate, deactivate, or restart revisions. Audit image provenance, registry permissions, ingress settings, identity assignments, and logs before routing production traffic to a new revision. before approvals. before release approvals and incident investigations.
Cost
A revision is not a separate billing SKU, but it affects cost through replicas, workload profiles, CPU, memory, and traffic routing. In multiple revision mode, two or more active revisions can run at the same time, which may double baseline replica cost during testing, canary, or blue-green periods. Inactive revisions usually do not run replicas, but retaining too many can complicate operations. Cost also appears when bad revisions crash-loop, emit excessive logs, or keep minimum replicas active. FinOps reviews should connect release strategy to replica counts, workload profile capacity, Log Analytics volume, and how long parallel revisions remain active. monthly.
Reliability
Reliability is one of the main reasons revisions exist. A new revision can fail provisioning, degrade because replicas crash, or remain unready because probes fail, while the previous revision continues to serve traffic. That separation reduces blast radius when release gates are used correctly. Operators should monitor provisioning state, running state, replica count, health probes, traffic weights, and logs per revision. Deactivating a stable revision too early removes a rollback option. Reliable release plans keep at least one known-good revision available, define when to restart versus redeploy, and use labels or traffic weights to shift users safely. during rollout. safely.
Performance
Performance impact depends on the revision’s image, startup path, CPU and memory allocation, scale rules, probes, and traffic share. A new revision can be slower because of a larger image, cold start, changed dependencies, or different concurrency behavior. Multiple active revisions can make performance testing precise because traffic can be split and measured before full cutover. Operators should compare latency, error rate, replica scale-out, CPU, memory, and startup time by revision. Do not average metrics across revisions during rollout; the old version may hide the new version’s slowness until the final traffic switch. across deployment stages. under load.
Operations
Operators inspect revisions during every meaningful Container Apps release. They list active and inactive revisions, show revision details, compare images and environment variables, read revision-scoped logs, restart revisions after secret changes, and deactivate versions no longer needed. Pipelines can wait for the new revision to reach a healthy running state before changing traffic. Incident runbooks should capture revision name, image tag or digest, traffic weight, replica status, revision suffix, labels, timestamps, and recent changes. Cleanup matters too: too many inactive revisions create noise, while deleting rollback candidates too aggressively weakens recovery. across release, incident, rollback, evidence, and cleanup workflows. reliably.
Common mistakes
Troubleshooting only the container app and ignoring which revision actually serves production traffic.
Deactivating the previous revision before the new revision has passed probes and real user checks.
Assuming a secret update is visible to existing replicas without restarting affected revisions.
Averaging metrics across revisions and missing that the canary revision has worse latency or errors.