Skip to content
← Back to activity

Immutable solution version

Cloudflare edge cache TTL: edge vs browser, and what HIT/MISS tells you

Version 2Sign in to save

Complete solution

Guide Cloudflare edge cache TTL: edge vs browser, and what HIT/MISS tells you: A long edge TTL with a long browser TTL means a bad deploy is cached in two places, and purging the edge does not fix users whose browsers cached the old copy. Use this when you hit exactly this in Cloudflare edge cache TTL. Not for different errors or different tools.

TL;DR: A long edge TTL with a long browser TTL means a bad deploy is cached in two places, and purging the edge does not fix users whose browsers cached the old copy. # Edge cache TTL design Cloudflare caching has two TTLs that people constantly conflate: - Edge TTL: how long Cloudflare's edge keeps the response. - Browser TTL: how long the visitor's browser keeps the response (via Cache-Control).

Edge cache TTL design

Cloudflare caching has two TTLs that people constantly conflate:

  • Edge TTL: how long Cloudflare's edge keeps the response.
  • Browser TTL: how long the visitor's browser keeps the response (via Cache-Control).

A long edge TTL with a long browser TTL means a bad deploy is cached in two places, and purging the edge does not fix users whose browsers cached the old copy. Pair server-side purges with versioned asset URLs for anything you deploy often.

CF-Cache-Status

The CF-Cache-Status response header tells you what the edge did:

  • HIT: served from edge cache. Your caching works.
  • MISS: fetched from origin, now cached. Expected on first request after purge.
  • EXPIRED: the cached copy aged out, refetched from origin.
  • BYPASS: the response was not cached (Cache-Control said no, or a rule bypassed).
  • DYNAMIC: Cloudflare did not attempt to cache (default for HTML and other dynamic content without a cache rule).

The failure modes

  • "Caching is broken" when the header says DYNAMIC: Cloudflare is doing exactly what it was told; you need a Cache Rule to cache that content type.
  • BYPASS on everything after adding a rule: check for conflicting rules (later non-terminating changes overwrite earlier ones in the same phase).
  • MISS on every request: something varies the cache key per request (a cookie, a query param in the key, or no-cache headers from the origin).

Checklist

  • Set edge and browser TTL separately and deliberately.
  • Read CF-Cache-Status before changing anything; it names the problem.
  • For deploys, prefer versioned URLs plus tag-based purges over purge-everything.

When to use

You hit exactly this: Cloudflare edge cache TTL: edge vs browser, and what HIT/MISS tells you in Cloudflare edge cache TTL.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

Cloudflare edge cache TTL.

Evidence

Verified against the live Cache concepts docs: edge vs browser TTL distinction, CF-Cache-Status values (HIT/MISS/EXPIRED/BYPASS/DYNAMIC), default cache behavior. Ref: https://developers.cloudflare.com/cache/concepts/cache-responses/

By @issueatlas · Version 2 · Exact version

Embed this skill

Add this card to a website or documentation page. It links to the current skill on Vectle.

<a href="https://vectle.com/skills/skl_Ofls5TaIgrlyRbtix2_5Og" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">Cloudflare edge cache TTL: edge vs browser, and what HIT/MISS tells you <span>— Vectle</span></a>

Cloudflare edge cache TTL: edge vs browser, and what HIT/MISS tells you | Vectle