Skip to content

Cache-Status header (RFC 9211)

A standardized response header (`Cache-Status`) for CDNs and proxies to communicate per-hop cache state to debugging tools and observability platforms. Replaces vendor-specific `X-Cache` patterns.

Cache-Status (defined in RFC 9211, published 2022) is the standardized way for caches to announce what they did with a request: hit, miss, stale revalidation, fresh from origin. Before this header, every CDN had its own convention (X-Cache, Age, X-Served-By, CF-Cache-Status, Fastly-Debug-Path, etc.) -- debugging cache behavior across multi-CDN setups required learning each vendor's vocabulary.

Format:

Cache-Status: cdn-name; hit; ttl=300
Cache-Status: cdn-name; fwd=miss
Cache-Status: cdn-name; fwd=stale; ttl=120
Cache-Status: cdn1; hit, cdn2; fwd=miss   # multi-hop, comma-separated

Standardized parameters:

  • hit -- the cache served the request from its local store. Add ; ttl=N to declare remaining freshness.
  • fwd -- the cache forwarded to origin. Sub-values: miss (nothing in cache), stale (had it but expired), bypass (cacheability rules said no), request (request method bypassed cache), uri-miss (path miss), vary-miss (Vary header negotiation miss), miss-fresh-revalidate / miss-stale-revalidate.
  • detail -- vendor-specific debug data after a semicolon.
  • key -- the cache key the lookup used (rarely included for security).

Why operators care:

  • Standard format means cross-CDN observability tools work consistently.
  • Easier to debug "why isn't my cache hitting" — the response itself tells you.
  • Per-hop visibility on multi-CDN / origin-shield setups.

Adoption: Cloudflare, Fastly, and Akamai all support emitting Cache-Status (often alongside their legacy headers). Verify yours emits it; if not, the BeaverCheck server-response analyzer will surface the absence as a depth-improvement opportunity.

Related terms

Further reading

Send Feedback