Active revision is the Container Apps revision that is allowed to receive traffic. In everyday Azure work, teams use it to roll out a new container image, keep a rollback candidate warm, or split traffic between versions. The useful evidence is revision mode, active state, replica health, labels, and traffic weight. Treat the term as an operating handle, not trivia: know who owns it, which boundary it affects, what could break, and which Azure output proves the current state before a production decision.
Container Apps active revision, revision activation, active Container Apps revision
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-09T05:20:00Z
Microsoft Learn
An active revision is an Azure Container Apps revision that is eligible to serve traffic. Revision mode controls whether one or many revisions can be active, and operators use active revisions with traffic weights, labels, and rollback decisions for canary, blue-green, and safe production releases.
In Azure architecture, Active revision sits in the Azure Container Apps application lifecycle layer, between image deployment and ingress routing. It works with container image versions, revision modes, traffic splitting, probes, scale rules, secrets, managed identities, labels, and Log Analytics. The important distinction is whether the reader is inspecting configuration, runtime behavior, identity, billing, or observability evidence. A strong design records scope, owner, permissions, monitoring signal, and rollback path so the term can be checked consistently across development, test, and production environments.
Why it matters
Active revision matters because it turns an Azure label into a decision point that operators can inspect, govern, and improve. Used well, it keeps work tied to evidence such as revision mode, active state, replica health, labels, and traffic weight. Used poorly, users may hit the wrong code path, a bad release may expand too quickly, or a rollback target may be deactivated before it is needed. The practical value is judgment: knowing which setting or record proves reality, which team owns the next action, and which failure mode to check first during a release, audit, incident, or cost review. Good entries make that decision path clear enough for production use.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
Azure Container Apps revision blade
Signal 02
az containerapp revision commands
Signal 03
revision labels and traffic-split views
Signal 04
deployment history and rollback runbooks
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Canary release for a new image
Blue-green deployment with rollback
Keeping a previous revision active during migration
Comparing error rate between versions
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Active revision in action
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
Northbridge Health, a healthcare organization, needed to release a patient portal API without risking scheduling outages during clinic hours.
🎯Business/Technical Objectives
Limit new release traffic to 10 percent for the first hour
Keep the previous version ready for rollback for 24 hours
Hold portal error rate below 1 percent during rollout
Cut manual deployment validation from 90 minutes to 30 minutes
✅Solution Using Active revision
The team used Active revision as the central control point for the workflow instead of treating it as a background setting. They enabled multiple-revision mode, activated the new revision, pinned a label for QA validation, and shifted traffic in stages from 10 to 50 to 100 percent while Application Insights tracked request failures and Container Apps replica health. Configuration was captured as code where practical, CLI output was saved for release or audit evidence, and monitoring was tied to the specific resource, run, or event pattern so responders could validate behavior without guessing.
📈Results & Business Impact
Production rollback time dropped from 25 minutes to under 4 minutes
The team detected a bad dependency setting at 10 percent traffic and avoided a clinic-wide outage
Release validation time fell by 62 percent
Minimum-replica cost increased only 6 percent during the controlled canary window
💡Key Takeaway for Glossary Readers
Active revisions make Container Apps releases safer because traffic can move gradually while a proven revision remains available.
Case study 02
Active revision in action
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
Aster Freight, a logistics organization, had nightly container deployments that sometimes broke rate-quote APIs for regional dispatch centers.
🎯Business/Technical Objectives
Separate build success from production traffic promotion
Give operations a one-command rollback path
Compare latency between two revisions under real load
Reduce failed deployment incidents by at least 50 percent
✅Solution Using Active revision
The team used Active revision as the central control point for the workflow instead of treating it as a background setting. They used active revisions as release gates: new images created inactive staging candidates, release engineers activated only the approved revision, split 20 percent of traffic to it, and used Azure Monitor metrics plus revision logs to confirm health before deactivating the previous version. Configuration was captured as code where practical, CLI output was saved for release or audit evidence, and monitoring was tied to the specific resource, run, or event pattern so responders could validate behavior without guessing. The final design included an owner, rollback or revoke path, and a standard evidence checklist so the same process could be repeated during audits, incidents, and production release windows.
📈Results & Business Impact
Failed deployment incidents fell from six per quarter to two
P95 quote latency improved 18 percent after comparing revisions
Rollback drills completed in under 5 minutes
Change tickets now include revision names and traffic percentages as evidence
💡Key Takeaway for Glossary Readers
An active revision is the operational switch that determines which deployed container version customers actually use.
Case study 03
Active revision in action
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
WillowPay Services, a financial technology organization, needed blue-green releases for a fraud scoring API with strict audit requirements.
🎯Business/Technical Objectives
Preserve a full audit trail of production revisions
Route less than 5 percent of traffic to unproven scoring changes
Keep fraud decision latency below 250 ms
Document rollback evidence for compliance review
✅Solution Using Active revision
The team used Active revision as the central control point for the workflow instead of treating it as a background setting. They kept two active revisions during release windows, assigned stable labels to blue and green revisions, routed a small percentage of traffic to the candidate, and captured CLI output showing active state, traffic weights, image digest, and promotion time. Configuration was captured as code where practical, CLI output was saved for release or audit evidence, and monitoring was tied to the specific resource, run, or event pattern so responders could validate behavior without guessing. The final design included an owner, rollback or revoke path, and a standard evidence checklist so the same process could be repeated during audits, incidents, and production release windows.
📈Results & Business Impact
Compliance auditors received complete revision evidence in each release record
Emergency rollback required only a traffic-weight change, not a redeployment
💡Key Takeaway for Glossary Readers
Active revisions let teams prove exactly which container version served traffic during controlled releases.
Why use Azure CLI for this?
Azure CLI is useful for Active revision because it turns portal knowledge into repeatable evidence. az containerapp revision list, show, activate, deactivate, restart, and traffic commands provide repeatable release evidence. Use CLI when you need inventory, comparison between environments, release notes, audit proof, or a safe pre-change check. Prefer read-only commands first, save structured output when possible, and treat mutating commands as change-controlled work with subscription, resource group, identity, and rollback details verified before execution.
CLI use cases
Inventory the Azure resources or records related to Active revision and confirm the expected scope.
Inspect revision mode, active state, replica health, labels, and traffic weight before a release, audit, incident review, or cost discussion.
Compare development, test, and production settings so drift is visible before users are affected.
Export structured evidence for tickets, runbooks, compliance reviews, or post-incident timelines.
Before you run CLI
Confirm the signed-in tenant, subscription, resource group, and target resource name before trusting output.
Check whether the command is read-only, mutating, credential-revealing, or potentially destructive.
Use the least-privileged identity that can inspect the resource and avoid pasting secrets into shared channels.
Decide the output format first, usually table for humans and JSON for automation or saved evidence.
Know the rollback or revoke path before running any command that changes state or permissions.
What output tells you
The output should identify the current Azure scope and show whether Active revision is configured, active, enabled, or producing evidence.
Status, timestamps, IDs, names, and related resource references help connect Active revision to a real owner and workload.
Empty output is still evidence: it may mean the feature is disabled, the wrong scope was queried, or the caller lacks permission.
Differences between environments usually point to drift, incomplete deployment, stale configuration, or an undocumented exception.
Mapped Azure CLI commands
Container Apps revision commands
direct
az containerapp revision list --name <container-app> --resource-group <resource-group> --output table
az containerapp revisiondiscoverContainers
az containerapp revision show --revision <revision-name> --name <container-app> --resource-group <resource-group>
az containerapp revisiondiscoverContainers
az containerapp revision activate --revision <revision-name> --name <container-app> --resource-group <resource-group>
az containerapp revisionoperateContainers
az containerapp revision deactivate --revision <revision-name> --name <container-app> --resource-group <resource-group>
az containerapp revisionoperateContainers
az containerapp ingress traffic set --name <container-app> --resource-group <resource-group> --revision-weight <revision-name>=10
az containerapp ingress trafficconfigureContainers
Architecture context
In Azure architecture, Active revision sits in the Azure Container Apps application lifecycle layer, between image deployment and ingress routing. It works with container image versions, revision modes, traffic splitting, probes, scale rules, secrets, managed identities, labels, and Log Analytics. The important distinction is whether the reader is inspecting configuration, runtime behavior, identity, billing, or observability evidence. A strong design records scope, owner, permissions, monitoring signal, and rollback path so the term can be checked consistently across development, test, and production environments.
Security
Security for Active revision starts with knowing the access boundary it creates or exposes. Review which image, secret references, managed identity, ingress setting, and environment variables are serving users before trusting the configuration in production. Least privilege, source verification, and clear ownership matter because a small Azure setting can change who can read data, trigger actions, approve permissions, or serve user traffic. Security teams should capture evidence in tickets or runbooks without leaking secrets, tokens, sensitive payloads, or customer data. When possible, pair the term with Microsoft Entra roles, managed identities, policy, logging, and alerting so changes are visible, reviewable, and reversible.
Cost
Cost impact for Active revision may be direct or indirect, but it should still be explicit. The main cost consideration is that multiple active revisions can keep extra replicas warm, especially when minimum replica settings are used during canary windows. Even when the term is not a billing meter, it can influence the services, retries, alerts, storage, model tokens, compute, or operations effort consumed around it. FinOps review should ask whether the setting is needed, who pays for it, how long evidence is retained, and whether tags, budgets, exports, or Advisor data make the spend explainable. Review the pattern whenever environments are cloned, scaled, or retired.
Reliability
Reliability depends on how Active revision behaves during failure, scale, retries, and change windows. The main reliability concern is safe canary rollout, blue-green traffic control, and fast rollback to a known-good revision. Operators should know whether the term affects runtime traffic, orchestration state, alert delivery, recovery evidence, or only management-plane reporting. Before changing it, confirm the rollback path, expected health signal, blast radius, and dependency map. During incidents, use the term to narrow the question: what changed, what is active, what failed, and what evidence proves that the system can safely continue or recover? Keep that evidence close to the change record.
Performance
Performance impact for Active revision depends on where it sits in the workload path. The main performance factor is latency, cold starts, replica counts, probe timing, and dependency calls can differ by revision. Some terms do not speed the application directly, but they improve operational performance by reducing investigation time, noisy processing, or manual triage. Review latency, throughput, queue depth, query shape, token usage, retry behavior, and data volume where they apply. The best test is practical: can the team prove the term improves user experience, deployment speed, incident response, or processing efficiency without hiding a new bottleneck? Measure before and after; assumptions are not evidence.
Operations
Operationally, Active revision should be part of a repeatable runbook, not a portal-only memory. Teams need a standard way of listing revisions, comparing traffic weights, watching logs and health, and documenting the rollback candidate. The runbook should name the Azure scope, owner, required role, normal state, change procedure, evidence to collect, and escalation path. Good operators also record why a value exists, not just what it is. That context prevents accidental cleanup, noisy alerts, unsafe reruns, stale dashboards, and confusing handoffs between platform, application, data, security, and finance teams. It also makes later reviews faster and less political. This keeps reviews repeatable when pressure is high.
Common mistakes
Treating Active revision as a label instead of checking the Azure output that proves its current state.
Using the wrong tenant, subscription, project, database, or resource group and then trusting misleading results.
Saving sensitive keys, payloads, user data, or permission details in screenshots instead of sanitized evidence.
Changing production configuration without documenting the owner, rollback path, alert impact, and expected verification signal.