← Cache / cache / concepts

Cloudflare cache responses

The CF-Cache-Status header output indicates whether a resource is cached or not. To investigate cache responses returned by this header, use services like Redbot ↗, webpagetest.org ↗, or a visual tool like Cloudflare Optics plugin ↗.

`Age` response header

The Age response header is returned when Cloudflare serves a response from cache. It is the number of seconds an asset has been in Cloudflare's cache since it was admitted or last revalidated, and it resets on revalidation against the origin, on purge, or on eviction. With Tiered Cache, Age reflects the object's age in Cloudflare's network-wide cache — a HIT served locally can carry an Age inherited from an upper tier, so the value can be older than the last local fill.

Cloudflare sets Age on HIT, STALE, and UPDATING responses. It does not set Age on MISS, on EXPIRED or REVALIDATED when the request revalidated against the origin, on DYNAMIC, BYPASS, or NONE/UNKNOWN. If the origin sets Age on an uncacheable response, that value is proxied to the client unchanged — a DYNAMIC or BYPASS response can carry an Age that came from the origin, not from Cloudflare.

Below you can find a comprehensive breakdown of Cloudflare's cache response statuses.

HIT

The resource was found in Cloudflare's cache.

MISS

The response is eligible for cache but was not present in Cloudflare's cache at request time, so it was served from the origin web server. Responses that Cloudflare chooses not to cache return BYPASS instead of MISS.

NONE/UNKNOWN

Cloudflare generated a response that denotes the asset is not eligible for caching. This may have happened because:

A Worker generated a response without sending any subrequests. In this case, the response did not come from cache, so the cache status will be none/unknown.
A Worker request made a subrequest (fetch). In this case, the subrequest will be logged with a cache status, while the main request will be logged with none/unknown status (the main request did not hit cache, since Workers sits in front of cache).
A WAF custom rule was triggered to block a request. The response will come from the Cloudflare global network before it hits cache. Since there is no cache status, Cloudflare will log as none/unknown.
A redirect rule or Always Use HTTPS caused the global network to respond with a redirect to another asset/URL. This redirect response happens before the request reaches cache, so the cache status is none/unknown.

EXPIRED

The resource was found in Cloudflare's cache but was expired and served from the origin web server.

STALE

The resource was served from Cloudflare's cache but was expired. Cloudflare could not contact the origin web server to retrieve an updated resource.

BYPASS

Cloudflare considered the asset eligible for cache at request time — either because it matches the default cached file extensions, or because a Cache Rule enabled caching for it — but the origin response was ultimately not cacheable.

Common reasons the origin response is treated as not cacheable include:

The response exceeds the maximum cacheable file size for your plan.
The origin returned no-store or bare private in a Cloudflare-CDN-Cache-Control or CDN-Cache-Control header. Cloudflare evaluates these headers ahead of Cache-Control, in the precedence Cloudflare-CDN-Cache-Control > CDN-Cache-Control > Cache-Control — so an origin returning Cache-Control: public, max-age=3600 together with CDN-Cache-Control: no-store produces BYPASS. A Cache Rule with an Edge Cache TTL setting that ignores origin cache-control overrides these directives, same as it does for Cache-Control: no-store. no-cache, max-age=0, or s-maxage=0 in these headers do not produce BYPASS. They produce MISS on the first request, then REVALIDATED or EXPIRED. Refer to CDN-Cache-Control for the precedence rules.
The origin returned Cache-Control: no-store or private. These directives prevent caching in either Origin Cache Control mode.
The origin returned Cache-Control: no-cache, max-age=0, or s-maxage=0, and Origin Cache Control is disabled (the default on Enterprise plans). With Origin Cache Control enabled (the default on Free, Pro, and Business plans), these directives cause Cloudflare to cache and revalidate the response instead, producing REVALIDATED or EXPIRED. Refer to Understand no-store and no-cache directives and the Conditions table.
The origin returned a Set-Cookie header. Refer to Interaction of Set-Cookie response header with Cache for the specific configurations that produce BYPASS.
The origin returned a Vary: * response header, which always bypasses cache.
The request included an Authorization header and Origin Cache Control is enabled (the default on Free, Pro, and Business plans). In that mode, the response is cacheable only if Cache-Control also includes public, s-maxage, or must-revalidate. On Enterprise plans with Origin Cache Control disabled, Authorization does not by itself prevent caching.

BYPASS means the decision not to cache was made at response time — the request was initially eligible for caching, but the origin response or response headers instructed Cloudflare not to cache. For example, a Cache Rule that sets "cache": true enables caching at request time, but if the origin returns Cache-Control: no-store, the response will be BYPASS.

If you expected a URL to be cached but see BYPASS, refer to Investigate uncached responses for a step-by-step diagnostic.

REVALIDATED

The origin confirmed the cached resource was unchanged via a conditional request (If-Modified-Since or If-None-Match), and the response is served from Cloudflare's cache. This status reflects the synchronous validation path — the request waits for the origin to respond before being served.

With asynchronous stale-while-revalidate, most revalidations now return UPDATING or HIT instead. REVALIDATED is seen in the following situations: stale-while-revalidate is not set; or directives like must-revalidate or no-cache (with Origin Cache Control enabled) prevent stale content from being served.

UPDATING

The resource was expired but served from Cloudflare's cache while the origin updates it in the background. UPDATING is the expected status during asynchronous stale-while-revalidate revalidation — all requests during the revalidation window receive UPDATING or HIT rather than waiting for the origin.

DYNAMIC

Cloudflare determined at request time that the asset is not eligible for cache, so the request went to the origin web server without a cache lookup.

This typically happens when:

The requested asset is not one of the default cached file extensions (for example, HTML or JSON) and no rule instructs Cloudflare to cache it.
A Cache Rule with the Bypass cache setting matches the request. The legacy Cache Level: Bypass option in Configuration Rules or Page Rules behaves the same way.
Development Mode is enabled on the zone, which suspends cache for three hours.

Use Cache Rules to change what content Cloudflare caches. Once the request is treated as eligible for cache, the CF-Cache-Status header will reflect the response-time cache decision (HIT, MISS, EXPIRED, REVALIDATED, BYPASS, and so on) — refer to BYPASS for the case where the origin response is ultimately not cacheable.

If you expected the request to be eligible for cache but see DYNAMIC, refer to Investigate uncached responses.