Interpreting CF-Cache-Status during performance testing

Choose the exact URL and note whether it is public, personalised or dynamic. Use browser Network tools or a request tool and make sure you are observing a response from Cloudflare.

1. Request the URL and record CF-Cache-Status, Cache-Control, Set-Cookie, Age where present and response status.
2. Interpret HIT as a cached response and MISS as an eligible object that was not already available at request time.
3. Treat DYNAMIC as a request that was not eligible for cache, and BYPASS as a response-time decision not to store or use ordinary caching under the applicable policy.
4. For EXPIRED, REVALIDATED, STALE or UPDATING, inspect the freshness and origin-revalidation context rather than assuming the content is necessarily wrong.
5. Repeat controlled requests and compare the intended policy. Investigate rules or application headers only where actual behaviour differs from that design.

Run this diagnostic twice from the same location against an actual public asset served through Cloudflare. It requests the file while displaying headers and discarding the body, so you can compare cache behaviour without mistaking browser-local reuse for a new edge request.

curl --silent --show-error --dump-header - --output /dev/null \
  --connect-timeout 3 --max-time 15 \
  'https://static.example.com/assets/site.8a41c2ef.css'

Record CF-Cache-Status, Age, Cache-Control, status and any cookie-setting behaviour. A first MISS followed by HIT can be normal for eligible content, but storage, rules, location and eviction influence the result. A private page should not be forced into the same pattern.

Expected result: The observed status matches the asset’s intended policy and correct content. A non-HIT response leads to a specific header or rule investigation, rather than an automatic conclusion that the website is broken.

A public asset may progress from MISS to HIT, while a private account page should remain outside shared caching. Different edge locations and cache eviction can produce different observations.

A Worker-generated response, redirect or security action can have no ordinary cache status. Browser-local caching can also prevent a new network request entirely. Check the relevant layer before altering CDN settings.

No. It can be a normal first fetch of eligible content. Diagnose failures from the response body, HTTP status and origin evidence, not the cache label alone.

• Checking why cookies prevent or alter Cloudflare caching
• Purging one changed asset from Cloudflare cache
• Distinguishing browser cache lifetime from edge cache lifetime
• Bypassing cache for private account and checkout pages

• Cloudflare: Cache Responses

• curl command options