Degraded Mode
Degraded mode is an explicit operating state with reduced functionality, entered deliberately under failure and exited through defined recovery criteria.
Definition
Degraded mode is a documented state in which a system serves a reduced feature set or quality of service while dependencies or capacity recover.
Context and scope
Used during dependency outages, regional failover, maintenance, and overload, where operators must decide what to disable and when to restore.
Common misconceptions
- Degraded mode is just a nicer error page
- A service leaves degraded mode automatically once errors stop
- Degraded mode only matters to large platforms
Anti-patterns
- Entering degraded mode with no runbook, owner, or user message
- Leaving features disabled after recovery because nobody owns the exit
- Disabling capabilities without informing support or customers
Related concepts
Authoritative source
https://learn.microsoft.com/en-us/azure/well-architected/reliability/
An explicit state, not an accident
Degraded mode is a named operating state in which the system intentionally serves less: read-only access, cached results, disabled exports, or a single region serving global traffic. The important word is intentional. A system that happens to return errors is broken; a system in degraded mode has a known scope, a known owner, and a plan. Compared to a full outage, it preserves partial value. Naming the state lets responders communicate clearly and prevents ad hoc changes.
Entering the state
Entry should be a decision with criteria, not a reflex. Typical triggers include a dependency outage, sustained overload, a failed region, or data inconsistency that requires freezing writes. The runbook lists which feature flags to disable, in what order, and what users will see. Record the time, the trigger, and the operator. If entry is automated, keep a manual override and an audit trail.
Operating in it
While degraded, monitor the remaining critical paths more closely. Confirm that the reduced mode actually protects the bottleneck; disabling recommendations does not help if checkout still overloads the database. Watch for secondary failures: queues filling, caches expiring, batches accumulating. Support teams need scripts for the user-visible symptoms, and status communication should state what still works, not only what is broken.
Exiting
Define exit criteria in advance: the dependency healthy for a sustained window, queue depth back to normal, replication caught up, error rate within target. Re-enable features gradually and watch for a second wave of load. A common failure is leaving degraded mode enabled for weeks, silently costing revenue and trust. Assign an explicit owner and a review date.
Testing
Rehearse degraded mode in game days and fault injection exercises. Verify that feature toggles work, that the user interface explains the limitation, and that metrics distinguish degraded traffic from failures. For example, an airline can run its booking site in read-only mode while resuming writes in a controlled order.