cf-cache-status only tells the truth after you know what entered the cache key. Scheme, Host, path, and any custom key fields (device type, query allow-list, headers) decide whether two clients share a HIT; a Set-Cookie or Authorization that sneaks into a cacheable response — or a Vary that lists User-Agent — can turn a shared object into a near-permanent MISS/BYPASS farm. TTL is the second axis: edge TTL and origin Cache-Control / s-maxage must agree on what is allowed to be stored, while HTML (or any non-hashed entry shell) needs a short lifetime or a purge tag, and content-hashed JS/CSS can carry long immutable lifetimes without risking ChunkLoadError-style stale references.

After a Cache Rule or key change I hit the same URL twice and compare cf-cache-status with the live Cache-Control the edge actually saw. DYNAMIC or BYPASS on a path you expected to HIT usually means cookies, method, or a query string still in the key — not a broken POP. For release hygiene, tag document responses (Surrogate-Key / Cache-Tag style) so a deploy purges shells without flushing the immutable asset namespace; then confirm authenticated routes still BYPASS so personalised HTML cannot poison the shared key.