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=Nto 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.