> ## Documentation Index
> Fetch the complete documentation index at: https://agentconcepts.io/llms.txt
> Use this file to discover all available pages before exploring further.
# graceful-degradation
> Partial-failure-acceptable mode: when a component or dependency fails, the system continues with reduced functionality rather than total failure. The fallback path is designed-in, not improvised.
business computer-science medicine-and-health military-sciences transportation
# Graceful degradation
## Description
Graceful-degradation is the move of designing a system so that when a component or dependency fails, the system continues with reduced functionality rather than total failure. The diagnostic shape: there's a full-capability path that runs in steady state; there's a failure-detection mechanism; there's a pre-designed degraded path that takes over when failure is detected; users (or callers) are informed they're in degraded mode so they can adapt their behavior. The degraded path is *itself* a path, not an exception — it's a first-class operating mode, not "the system is broken and we caught the exception."
The structural insight is that total-failure-on-any-component-failure is a design choice, not an inevitability. Most systems implicitly accept total failure because the degraded path was never designed. Graceful-degradation makes the degraded mode a design deliverable — what's the read-only fallback if the write path is down? what's the stale-data response if the freshness path is down? what's the cached-result response if the live-compute path is down? The cheap-default is full capability; the fallback is degraded but still functional.
Graceful-degradation depends on two upstream concepts: bulkheads (so a single failure doesn't take everything down — there must be a meaningful "partial" to fail to) and circuit-breakers (so failure is detected quickly and the system actually switches modes rather than hanging on the failing dependency).
## Triggers
**User-initiated:** User describes a system that's currently all-or-nothing and wants partial-failure tolerance, or asks about fallback paths. Vocabulary cues: "graceful degradation," "fallback," "reduced functionality," "degraded mode," "read-only mode," "partial failure," "resilience."
**Agent-initiated:** Agent notices a system that depends synchronously on a component whose failure would propagate as total system failure, with no designed-in fallback. Candidate inference: "this wants graceful-degradation — what's the cheap default, what's the failure signal, and what's the pre-designed degraded path?"
**Situation-shape signals:** Synchronous dependency on a critical component; user-facing impact of dependency failure is unacceptably broad; observed cascading failures; capacity-overload scenarios that need a "shed load gracefully" mode.
## Exclusions
* **Correctness-critical operations where degraded output is worse than no output** — bank transfers, medical-record writes, security-critical operations; failing-loud is correct; degrading-silently is dangerous.
* **No meaningful "degraded" mode exists** — if the system's purpose is exactly one indivisible thing (e.g., authentication: either it works or you're locked out), there's no useful degradation point.
* **Designed-fallback would be misleading** — sometimes a degraded result that *looks* full-capability is worse than failure; the communication-to-consumers part of the concept is load-bearing here.
* **All-or-nothing regulatory or contractual obligations** — sometimes the contract says "no service if you can't deliver full service"; degradation isn't an option.
## Structure
\= **a full-capability default path + a timely failure signal + an explicit pre-designed degraded path + communication to consumers**. The structural form is cost-cascade where the cascade is failure-triggered: the cheap default runs when healthy; the fallback runs when the default is unavailable.
## Relationships
* [bulkhead](/concepts/bulkhead) — pre-requisite substrate; bulkheads create the failure domains that degradation operates within.
* [circuit-breaker](/concepts/circuit-breaker) — provides the failure-detection trigger.
* [cost-cascade](/concepts/cost-cascade) — structural pattern is conditional cascade from cheap-default to designed-fallback.
* [saga](/concepts/saga) — degradation applied to multi-step transactions.
* [caching](/concepts/caching) — caches as the stale-fallback path during origin failure.
## Examples
during a write-path outage, users can still browse and play; recommendations may be stale; new ratings can't be saved. The product survives.
when capacity is overwhelmed, treat the most-treatable first; accept loss of those who can't be saved; the protocol is the degradation policy.
flight overbooked; bumped passengers get compensation + rebooking; the system has a designed-in degradation policy with explicit cost.
Allspaw, J., various incident-response and resilience-engineering writing — graceful degradation as a sociotechnical property of teams + systems.
local ATM cash dispenses up to a daily limit even when central authorization is down; bounded-but-functional service.
Google's *Site Reliability Engineering* book (Beyer, Jones, Petoff, Murphy, eds., 2016) treats graceful degradation as a core design principle for large-scale services. The book argues that for services operating at internet scale, total availability is unachievable; what matters is what happens at the edge of capacity. Chapters on handling overload, addressing cascading failures, and load shedding develop the practice of *deliberately* serving a degraded experience under stress — dropping non-essential features, returning cached results, restricting expensive operations — rather than letting a service collapse entirely.
The SRE framing makes the structural decision explicit: rather than treat "service is up" as binary, define multiple modes (full, reduced, read-only, static-page, error) and design transitions between them. The book is now widely cited as the canonical practitioner reference for the concept in distributed-systems engineering.
JS-disabled, slow-network, old-browser fallback to baseline HTML+CSS. Canonical web-design instance.
when origin is unreachable, the CDN serves the last-known-good copy with a stale-warning header; better-than-nothing for read-mostly content.
Cederholm articulates progressive enhancement as the *positive* design principle of which graceful degradation is the failure-side mirror. Start from a semantically-clean HTML core that works in any browser, then layer CSS for presentation, then layer JavaScript for interactive enhancement — each layer optional, each layer additive. When the JavaScript layer fails (no JS support, parse error, network drop on a script tag), the site falls back to the CSS+HTML layer; when CSS fails, the HTML layer remains usable.
**Inference**: Progressive enhancement and graceful degradation describe the same architectural property from opposite directions — design-time discipline vs runtime behavior. The shared structural primitive is *stacked layers where each lower layer is independently sufficient*. The same shape transfers to API versioning (clients on older versions still get core function), feature flags (gracefully fall back when a flag service is unreachable), and to LLM prompt design (a prompt that still produces useful output when an optional context block is missing).
repo browsing remains available even when push / PR-merge are degraded; Status page communicates which capabilities are degraded.
Norman's chapter on error is graceful degradation applied to the human-machine interface. His starting premise is that human error is inevitable, so a good design does not try to prevent every mistake — it assumes mistakes will happen and keeps their consequences survivable. He reframes "human error" as bad design: if a slip or a mistake leads to catastrophe, the fault lies with a system that made the error both easy to commit and impossible to recover from.
The design moves he prescribes are exactly the graceful-degradation pattern at the interaction layer. Make errors *detectable* (immediate feedback so the user knows something went wrong before going further down the wrong path); make them *recoverable* (the Undo command as the canonical instance); make them *low-cost* (a forgiving system where failing does not lose work or cause damage); and where an action is genuinely irreversible, raise its cost deliberately ("Are you sure you want to delete all?"). His forcing functions — interlocks, lock-ins, lock-outs — are the constraints that keep a slip from escalating: a microwave that cuts power when the door opens, a program that won't close without offering to save.
**Inference**: The structural claim graceful degradation shares with Norman's "design for error" is that robustness comes from bounding the *consequences* of failure, not from eliminating failure. A system that demands perfect operation is brittle precisely because operators are not perfect; the resilient design assumes the error, makes it visible, and keeps a cheap path back. This is the same shape as a service falling back to read-only mode or a site serving stale-on-error — degrade the experience, preserve recoverability — expressed in the vocabulary of the user interface rather than the distributed system.
when the front line is untenable, retreat to a pre-prepared defensive line; the retreat is planned, not improvised.
Nygard's *Release It!* Chapter 5 is the canonical practitioner articulation of graceful-degradation patterns for production systems: timeouts, circuit breakers, bulkheads, steady-state pruning, fail-fast, handshaking, decoupling middleware. The shared shape across these patterns is *bound the blast radius and accept a degraded but functional state rather than total failure*. He frames each as a counter-doctrine against a specific failure mode that emerges from coupled distributed systems — e.g., circuit-breaker is a doctrine against retry-storms after a downstream collapse.
**Inference**: Graceful degradation is not a single move but a family of paired patterns (`circuit-breaker`, `bulkhead`, `rate-limiting`, `retry-with-backoff`) each targeting a specific cascade-failure mode. When designing for resilience, name the failure mode being targeted before picking the pattern; the catalog's structural overlap among these concepts is curatorially meaningful.
the cross-domain instance with the most-explicit design discipline; "progressive enhancement" articulates graceful-degradation as a positive design principle rather than only a failure-mode response
Windows Safe Mode, recovery shells; minimal-functionality boot when full-feature boot fails.