CDN Stale Content Serving: stale-while-revalidate and stale-if-error Patterns

Every CDN cache has an expiration moment where fresh becomes stale. Traditionally, that moment triggers a synchronous origin fetch that blocks the client. With stale-while-revalidate and stale-if-error, you change that contract: the edge can serve stale immediately while refreshing in the background, or serve stale when the origin is failing. Implemented correctly, these two directives cut tail latency by 60-90% and turn origin outages from hard downtime into invisible blips.

This guide explains how both patterns work at the HTTP and edge level, when to use them, and how to configure them safely without amplifying cache invalidation errors or serving poisoned content.

Why Serving Stale Beats Serving Nothing

Without stale directives, a cache hit lifecycle is simple: HIT if age < max-age, otherwise MISS and block. That blocking revalidation creates two problems at scale. First, thundering herds: when a popular object expires, thousands of edge requests serialize behind one origin fetch, spiking TTFB and origin load. Second, fragility: any 5xx or timeout during revalidation becomes a user-visible error, even though a perfectly usable previous version sits on disk.

Stale serving decouples delivery from validation. The edge answers from cache instantly, then reconciles with the origin asynchronously. For a deeper look at how TTLs and validation interact, see our CDN fundamentals guide and architecture overview.

Both directives were standardized in RFC 5861 and are now supported natively by Cloudflare, Fastly, Akamai, CloudFront, and modern browsers. They are not a hack; they are part of Cache-Control and CDN-Cache-Control semantics.

stale-while-revalidate: Hide Revalidation Latency

stale-while-revalidate (SWR) tells a cache: after max-age expires, you may serve the stale object for N additional seconds while you revalidate in the background. The client gets an instant stale response; the next client gets the fresh one.

How the state machine works

Consider Cache-Control: public, max-age=60, stale-while-revalidate=300:

• 0-60s: Fresh. Edge serves HIT, no origin contact.
• 60-360s: Stale but revalidatable. Edge serves STALE (often with Age header > 60) and fires an async conditional request (If-None-Match / If-Modified-Since) to origin. If origin returns 304, the object is refreshed. If 200, it is replaced.
• >360s: Beyond SWR window. Edge must block and revalidate synchronously.

The latency win is immediate. In production traces across edge networks, SWR reduces p95 TTFB for HTML from 250-400ms to 25-50ms during the revalidation window because no client waits for origin.

Note the split: browsers get a short max-age for freshness, while the CDN gets a longer one via CDN-Cache-Control (or Surrogate-Control on Fastly). This layered approach is critical for Core Web Vitals — you keep LCP fast at the edge without forcing browsers to hold stale HTML too long.

When to use SWR

SWR is ideal where slightly stale is acceptable and revalidation cost is high: SSR HTML, API responses for feeds and listings, product catalog pages, and image optimization manifests. It is less appropriate for personalized checkout, auth tokens, or inventory counts where staleness equals oversell.

Set the SWR window proportional to your origin update frequency and revalidation latency. A common pattern is max-age at 10-20% of SWR. For a news homepage updated every 60s, max-age=10, stale-while-revalidate=60 keeps 90% of requests instant while guaranteeing refresh within a minute.

stale-if-error: Survive Origin Failures

stale-if-error (SIE) is your circuit breaker. It says: if revalidation fails with an error (500, 502, 503, 504, or network failure), you may serve stale for N additional seconds rather than propagating the error.

Example: Cache-Control: public, max-age=60, stale-while-revalidate=300, stale-if-error=86400 means that even if the object is 12 hours stale, the edge will still serve it during an origin outage rather than returning a 500 to users. For many content sites, a 12-hour-old article is infinitely better than an error page.

SIE does not trigger on 4xx. A 404 or 403 is considered authoritative — the origin is saying the resource does not exist or is forbidden, so the cache should not mask it. Only 5xx and timeouts qualify. Some CDNs let you extend this to include 421, 429, or specific timeout thresholds; verify your provider's mapping.

Operationally, SIE turns a hard dependency on origin availability into a soft one. Teams that set stale-if-error=86400 to 604800 (1-7 days) for static assets and SSR shells routinely ride through 10-30 minute origin deploys, database failovers, and regional brownouts with zero user impact. Pair it with origin shielding and health checks so stale is a last resort, not a crutch for an unhealthy origin.

Implementation Across CDNs and Origins

Origin headers are the source of truth, but every CDN has an override layer. Configure both so behavior is predictable if headers are stripped.

1. Origin headers (recommended default)

2. CDN overrides

• Cloudflare: Cache Rules → Eligible for cache → Edge TTL + Stale while revalidate / Stale if error. Honors origin stale-while-revalidate by default when “Respect origin headers” is enabled.
• Fastly: beresp.grace (SIE) and beresp.stale_while_revalidate. Set via VCL or Compute. Surrogate-Control: max-age=300, stale-while-revalidate=86400 is respected.
• Akamai: Property Manager → Caching → “Serve Stale” options. Maps to stale-while-revalidate and stale-if-error behaviors.
• CloudFront: Cache policy + Origin request policy. Enable “StaleWhileRevalidate” and “StaleIfError” custom headers via Functions or origin headers; CloudFront now forwards and honors RFC 5861 directives when using Cache-Control origin.

Always emit ETag or Last-Modified so background revalidations can be conditional (304). Without validators, every SWR triggers a full 200 re-download, erasing bandwidth savings.

3. Browser vs edge separation

Use CDN-Cache-Control to give edges a longer SWR window than browsers. Browsers should not hold stale HTML for hours. Edges can. This avoids the classic mistake of setting stale-while-revalidate=86400 globally and then wondering why users see yesterday’s price after a hard refresh bypasses the CDN but not the browser cache.

Tuning, Risks, and Cache Poisoning Defense

Stale serving is powerful but amplifies mistakes. A poisoned object cached once can be served stale for days via SIE.

• Never apply SIE to unvalidated responses. Only cache 200/203/206/304 and explicitly validated 404s. Ensure your origin does not cache 500s. Set Cache-Control: no-store on 5xx at origin; let SIE handle stale at the edge instead.
• Key correctly. Include Vary: Accept-Encoding, Accept and any personalization keys. SWR on a cache key that collapses authenticated and anonymous variants will leak stale private data.
• Monitor stale ratios. Export Cache-Status or X-Cache headers (hit; stale; revalidated) to your observability stack. Alert if stale-if-error rate > 1% or if SWR revalidation error rate spikes.
• Purge with care. A purge should invalidate both fresh and stale copies. Verify your CDN purges grace/SWR copies; some require soft purge vs hard purge distinction.
• Test failure mode. Simulate origin 503 with a chaos test and confirm edge serves stale with Warning: 110 - Response is Stale rather than failing. Document expected staleness SLA for stakeholders.

When configured with layered TTLs, conditional revalidation, and proper cache keys, stale-while-revalidate and stale-if-error shift your CDN from a simple cache into a resilience tier — one that absorbs latency and outages so your origin does not have to be perfect to deliver a perfect user experience.