Stale-if-Error Trade-Offs for High Availability

The stale-if-error HTTP Cache-Control directive allows an edge cache, content delivery network (CDN), or browser to serve cached, expired responses when the origin server returns a 5xx error or fails to respond. While this policy dramatically improves perceived uptime and user experience during infrastructure outages, it introduces critical trade-offs regarding data freshness, observability, backend recovery, and state consistency.

Resilience vs. Data Freshness

The primary advantage of stale-if-error is high availability. When an origin database crashes or a deployment fails, end users continue to see functional pages rather than a generic error code.

The immediate trade-off is data accuracy. Serving stale data can have varying consequences depending on the resource:

  • Low Impact: Marketing pages, documentation, and blog posts remain usable even if the content is hours or days out of date.
  • High Impact: Financial balances, inventory levels, or breaking news updates become actively harmful when outdated. A user might purchase an item marked as in stock when the origin failure is masking inventory depletion.

Observability and Masked Failures

When edge caches serve stale content upon detecting backend errors, user-facing error rates remain near zero. While this satisfies service-level objectives (SLOs) for end users, it can blind engineering teams to active failures.

Traditional monitoring that relies on synthetic checks or client-side telemetry may report a healthy application while the origin server is in a crash loop. To counteract this, organizations must decouple edge-to-client metrics from edge-to-origin health metrics. Monitoring must explicitly alert on origin error spikes and cache-hit ratios for stale responses.

Recovery Waves and Cache Stampedes

When an origin service experiences transient degradation, stale-if-error shields it from continuous user traffic. However, the directive can exacerbate recovery:

  1. Simultaneous Expiration: If a prolonged outage exceeds the configured stale-if-error window, all cached stale assets expire concurrently, causing a massive traffic spike (thundering herd) that can knock the recovering origin back offline.
  2. Revalidation Overload: Once the origin recovers, edge nodes will immediately attempt to revalidate their stale assets simultaneously. Without request coalescing (collapsing identical pending requests into a single origin fetch), the burst of revalidations can trigger a secondary outage.

Security and State Synchronization

The stale-if-error directive is often applied globally via edge CDN configurations, which risks exposing dynamic or sensitive content.

If an authenticated endpoint or a route containing personalized user state is mistakenly cached with a fallback directive, users may receive outdated authorization states or corrupted session views. For example, a user who revokes account access or changes permissions might still see administrative panels if the edge masks an authorization failure by serving a previously cached response.

Implementation Strategy

To balance availability with correctness, teams should avoid applying blanket stale-if-error policies:

  • Scope by Content Type: Restrict aggressive stale windows to static or read-heavy public APIs. Keep the stale window narrow (e.g., minutes instead of days) for semi-dynamic data.
  • Exclude Sensitive Routes: Explicitly bypass stale-if-error for transactional, authenticated, and mutation-heavy endpoints using Cache-Control: no-store, private.
  • Pair with Asynchronous Revalidation: Combine stale-if-error with stale-while-revalidate and origin-shielding mechanisms to smooth out traffic spikes during both steady states and recovery phases.