Cloudflare `BYPASS` instead of a misleading `MISS`: how to quickly understand why an asset is not cached

Cloudflare``CDN``Caching``DevOps``Frontend``Backend

Since 2026-05-26, Cloudflare labels uncacheable responses more clearly as BYPASS, which makes it easier to tell when the fix belongs in origin headers, Cache Rules, or object-size limits

Hook

The most confusing part of cache debugging is often not the cache itself, but the signal you get back. If CF-Cache-Status looks like a MISS, it is easy to waste time on the wrong layer and start looking for a breakage that is not there.

On 2026-05-26, Cloudflare changed that signal: uncacheable responses are now labeled more clearly as BYPASS. For a practical team, that means simpler diagnostics. If the response is intentionally not cached, the status no longer hides that fact behind a generic miss.

What changed

CF-Cache-Status is not decorative. Its job is to show what happened to a specific response at the edge as quickly as possible.

After the change, Cloudflare separated two scenarios:

  • MISS - the response was not found at the edge, but it may still be cacheable;
  • BYPASS - Cloudflare decided not to cache the response.

That matters because the old overlap between those signals made people assume “the cache is broken” when, in reality, origin behavior or rules were making the response uncacheable by design.

What to check first

The troubleshooting order should stay very practical:

1. Inspect the response headers

The most common reasons a response is not cached are:

  • Cache-Control: no-cache
  • Cache-Control: private
  • Cache-Control: max-age=0
  • Set-Cookie
  • Authorization

If one of those signals is present, BYPASS may be normal and expected.

2. Check the asset size

Not every response is eligible for caching. If the asset is too large or exceeds your plan’s cacheable limits, the problem is not a broken CDN.

3. Look for Cache Rules

If the origin headers look fine but the behavior still seems odd, Cache Rules are the next layer. They can override the expected outcome for specific URLs.

4. Run a quick curl -I

For the first pass, this is often enough:

curl -I https://example.com/asset.css

Then check CF-Cache-Status, Cache-Control, Set-Cookie, and Authorization.

How to read the status codes without fooling yourself

The most useful part of this change is not the word BYPASS itself, but the fact that it removes ambiguity.

  • If you see BYPASS, look for the reason the response should not be cached.
  • If you see MISS, verify whether the response is cacheable and simply has not landed at the edge yet.
  • If you see HIT, the cache is behaving as expected.

So after this update, MISS is closer to “cacheable, but not in edge yet” than to “Cloudflare broke something.”

Practical order of operations

Here is the smallest useful sequence:

  1. Run curl -I against the problematic URL.
  2. Check Cache-Control, Set-Cookie, and Authorization.
  3. Confirm that the asset is within cacheable size limits.
  4. Review any Cache Rules that might change the behavior.
  5. Only then move on to deeper debugging.

This order works because it starts with the most likely causes instead of sending the team into open-ended CDN troubleshooting.

What BYPASS does not do

BYPASS does not magically fix caching, and it does not mean Cloudflare is broken.

It only makes the signal more honest:

  • if the response is uncacheable by policy, that is visible immediately;
  • if the response is cacheable but not present at the edge, you will see a different picture;
  • if the origin headers are the root cause, you find them sooner.

Bottom line

The most useful mental model is simple:

  1. BYPASS means the response should not be cached;
  2. MISS means a cacheable response was not yet present at the edge;
  3. start with headers, then size, then Cache Rules;
  4. do not confuse a diagnostic signal with a failure.

That is why this Cloudflare change matters not just as a product update, but as a small practical improvement to root-cause analysis.

Sources

Quick checklist

  • Check `CF-Cache-Status` on a real request.
  • Inspect `Cache-Control`, `Set-Cookie`, and `Authorization`.
  • Verify that the response is not above cacheable size limits.
  • Confirm whether origin behavior, not the edge, is deciding the outcome.
  • Check Cache Rules if origin headers do not explain the result.
  • Use `curl -I` for a quick repeat test.
  • Explain to the team that `BYPASS` is not a broken cache, but a reasoned decision not to cache.

Prompt Pack: diagnose why a Cloudflare asset is not cached

Help me quickly diagnose why an asset is not being cached by Cloudflare. Inputs: - CF-Cache-Status value; - response headers: Cache-Control, Set-Cookie, Authorization; - response size; - whether Cache Rules exist; - whether the asset comes from origin or is generated; - whether origin behavior changed recently. Return: 1. a short verdict: cacheable, bypassed, or needs deeper debugging; 2. the most likely cause; 3. which headers to check first; 4. when to look at object size or plan limits; 5. when to move on to Cache Rules; 6. a short next step using curl -I. Format: verdict, evidence, likely cause, next checks, recommended fix.