2026-09-21 · 6 min read · Rahul Chitturi
- http
- caching
- reliability
stale-while-revalidate can permit a cache to serve an old response while it refreshes in the background, while stale-if-error can permit stale reuse when contacting the origin fails. They improve availability but intentionally expose older content.
A surprising stale response may be correct under one cache's age calculation and policy even when another layer already considers the object unusable.
Calculate the response timeline
Capture Date, Age, Cache-Control, validators, request directives, cache status, revalidation timestamps, and the final response source. Calculate freshness lifetime first, then the applicable stale window.
- Distinguish stale serving from a normal cache hit.
- Record whether background revalidation actually started.
- Classify timeout and origin error behavior explicitly.
- Protect responses that must never be served stale.
Map layered cache policy
Browsers, service workers, CDNs, reverse proxies, and application caches can each apply different support and limits. Compare field changes and cache keys at every layer instead of attributing all stale behavior to the browser.
Revalidation should use validators when available and prevent uncontrolled request bursts. Decide how authentication, personalization, invalidation, purge, and deployment rollback interact with stale reuse.
Exercise outage boundaries
Use Flashman's timestamp converter for age timelines, diff for response fields, URL tool for safe cache-key fixtures, and units converter for duration and payload budgets.
Test just before and after freshness expiry, each stale-window boundary, successful and failed revalidation, timeouts, 5xx responses, concurrent requests, purges, variant keys, directives that forbid storage, and recovery after an outage.