Cloudflare Cache: When to Invalidate or Purge?

Use Cloudflare invalidation when cached content may be unchanged and you want a later request to check it against the origin. Use purge when the old content must not be served again, such as material removed for legal or security reasons. Invalidation marks cached content stale; it does not fetch or publish a replacement immediately. A later request triggers revalidation, and the result depends on the cached object, origin validators, and your cache setup.

This guide is for site owners and developers checking a deploy or cache change. Cloudflare’s Application Performance changelog dates its invalidation feature to September 28, 2026, and describes revalidation on the next request. The practical decision is still about whether the old response may be reused and whether it is safe for stale content to appear while revalidation occurs.

What invalidation changes

Cloudflare documents invalidation as marking cached content stale. On a later request, Cloudflare can use the origin’s ETag or Last-Modified value to make a conditional request. If the origin returns 304 Not Modified, Cloudflare can reuse the cached response. If the object is no longer cached, the origin provides no usable validator, or conditional requests are unsupported, Cloudflare fetches a full response instead. See Cloudflare Docs: Invalidate Cached Content.

That makes invalidation a reasonable candidate after a deploy when some cached files may be unchanged. It is not a way to force an immediate fetch of every changed file. Cloudflare’s API guidance on invalidating cached content recommends purge when content must not be served again. Choose based on the consequence of an old response reaching a visitor, not just on which button or API call is quicker.

Run a controlled invalidation test

Cloudflare’s documented test conditions are important: choose a cacheable URL with a positive TTL, make sure the response does not have a stale-while-revalidate directive, and leave the origin content unchanged during the test. Without these conditions, a status change may have another explanation.

Choose a safe test URL. Use a non-sensitive object that is meant to be cached. Confirm the URL’s cache rules, cache key, and target selector. Use the same URL and request conditions throughout so you are testing the same cache entry.
Check the origin and cache prerequisites. Confirm that the response is cacheable, has a positive TTL, and does not include stale-while-revalidate. Check whether the origin sends an ETag or Last-Modified header and whether its logs record conditional requests.
Establish a cache HIT. Request the test URL and inspect CF-Cache-Status. Repeat as needed until you have established a HIT for this test.
Submit the invalidation. Record the API response and confirm the selector identifies the intended cached object. A successful API response with HTTP 200 and success: true means Cloudflare accepted the request; it does not confirm what visitors will receive.
Request the same URL again. Record the request time, HTTP status, CF-Cache-Status, and relevant response headers. Then check the origin log for that request, including any conditional header and the origin response status.
Compare the content. Check that the body, image, or other content returned to your test client matches the version you intended. A header alone does not establish that the correct content is being delivered.

Hypothetical example: an unchanged product image

Suppose a store deploys a theme update that may change some images, but one product image is believed to be unchanged. The team chooses that image as a safe test object, confirms the cache conditions above, and records its current ETag and appearance before invalidating it.

After invalidation, the next request may reach the origin with a conditional header based on the validator. If the origin returns 304 Not Modified, that is evidence that the origin considers the representation unchanged and Cloudflare can reuse the cached response. If the origin sends a full response instead, investigate whether the image changed, whether the object was still cached, and whether the origin and request support the expected validator exchange. A full response does not, by itself, identify which of those explanations applies.

Finally, compare the image returned to your test client with the intended version. Treat the origin log, Cloudflare headers, and content check as complementary evidence—not as proof that every visitor or cache layer has already served the same result.

Interpret the result without overreading one header

Cloudflare documents several possible status outcomes. They are useful clues, not a guaranteed sequence for every request:

REVALIDATED followed by HIT can occur when the origin confirms the cached content is unchanged.
EXPIRED followed by HIT can occur when content has changed or could not be validated and Cloudflare fetches a full response.
UPDATING followed by HIT can occur when a stale response is served during revalidation.
STALE can occur when the origin fails during revalidation.

A visitor can receive HTTP 200 even when the origin returned 304: the visitor’s response and the origin’s conditional response are different parts of the exchange. Check the origin log to confirm whether revalidation occurred. Tiered Cache and concurrent requests can also affect the status a visitor sees, so a single request may not show the complete cache-layer behavior.

Depending on cache settings and directives, stale content may be served during revalidation or if the origin returns a 5xx response or cannot be reached. If serving the old content is unacceptable, follow Cloudflare’s purge guidance rather than relying on invalidation to prevent stale delivery.

Keep a compact verification record

The invalidation API response, recorded as acceptance rather than proof of the cache effect.
The test URL, target selector, request time, and the cache-key conditions relevant to the test.
The test response’s CF-Cache-Status, HTTP status, and relevant cache and validator headers.
The matching origin log entry, including conditional request headers and whether the origin returned 304 or a full response.
A content or version check showing whether the returned object matches the intended version.

If the results do not line up, first recheck the selector and cache key, then confirm the object was cached before invalidation and inspect the origin’s validator behavior. Keep Tiered Cache, concurrent requests, stale-serving conditions, and origin failures in mind when interpreting a visitor-facing response.

Have you tested Cloudflare invalidation against your origin logs? Share what evidence helped you distinguish revalidation from a full fetch, without posting private URLs or sensitive log data.

Sources

Cloudflare Docs: Invalidate Cached Content

Editorial note: AI assists with research, drafting and automated checks. Sources are linked so you can verify the guidance. Platform requirements can change; confirm the details that apply to your setup.