Cloudflare purge requests now force a Cache Reserve miss

When a purge request is issued, what happens to content held in Cache Reserve has been altered by Cloudflare. The company's changelog says that no matter which purge type is used, such requests now cause Cache Reserve content to be treated as a cache miss. Requests made through the API and through the dashboard are both covered by the change, which aligns Cache Reserve with the way the edge cache already deals with purges.

Under the earlier behaviour, the purge type made a difference. Content in Cache Reserve that matched was marked for revalidation when the purge was by cache tag, hostname, prefix or everything, whereas content was already removed from Cache Reserve when the purge was by URL. According to the changelog, the URL-based behaviour has not changed, so the shift is concentrated in the broader purge types that previously triggered revalidation rather than removal.

Operationally, this means that once a purge occurs, the following request for affected content results in a Cache Reserve miss. Since the content is no longer served from Cache Reserve, the origin has to deliver it in full even when the content itself is unchanged. The content is then written back into Cache Reserve by Cloudflare, and that write is billed as a Class A operation.

A second cost dimension is made explicit in the changelog. Content is not deleted from Cache Reserve immediately when the purge is by tag, hostname, prefix or everything. Until a later request replaces it or its retention period ends, matching content continues to incur storage costs. Put another way, the purge changes how the next request is served without instantly freeing the storage that the old copy occupies.

The change is framed by Cloudflare as a consistency improvement: purges are now handled by Cache Reserve in the same manner as the edge cache. For teams that had built assumptions around the older revalidation behaviour, that consistency comes with a different operational profile, because a forced miss means origin traffic and a fresh write rather than a conditional check against stored content.

For anyone who purges Cache Reserve content frequently by tag, hostname, prefix or everything, the changelog recommends reviewing the effect on origin egress and Cache Reserve usage. That advice is directed at the pattern most affected by the change, since repeated broad purges now translate into repeated full origin deliveries and repeated Class A writes.

Cloudflare also documents an alternative for teams that want to keep content in Cache Reserve and revalidate it instead of forcing a miss. The company points to a new invalidate_cache endpoint, illustrated in the changelog with a POST request to the zones endpoint carrying a bearer token and a JSON body containing a tags array. In the dashboard, the equivalent control is Invalidate Cache on the Caching > Configuration page.

Invalidation follows a distinct set of mechanics. Cloudflare reuses the stored content rather than fetching it from the origin once more when the origin returns a 304 Not Modified response. Invalidation cuts origin egress relative to purging, yet Cache Reserve operations are not reduced, and a 304 response that leads to updating the stored content remains a Class A operation. Sending a request to invalidate by URL likewise updates the stored content, and that too counts as a Class A operation.

The way stale content is handled is another point that distinguishes invalidation. Should the cache settings permit it, invalidation is able to serve stale content while revalidating, which differs from how purge behaved previously. According to the changelog, that capability applies only to copies held in the edge cache, and not to content that Cache Reserve serves. In addition, Cloudflare may serve invalidated content stale when the origin cannot be reached or responds with a 5xx error.

The distinction between the two paths is therefore not simply old versus new. Purging forces a miss and a full origin delivery; invalidation attempts revalidation and can reduce origin egress, but it does not reduce Cache Reserve operations and it still incurs a Class A operation when stored content is updated. Teams choosing between them are trading origin traffic against cache-write activity and storage retention.

For freelancers and small development teams running sites or APIs behind Cloudflare, the change is most likely to surface as a shift in origin load and in Cache Reserve billing after broad purges. A workflow that purged by tag to refresh a category of assets will now pull those assets from the origin in full on the next request, and the old copies remain billable for storage until replaced or expired.

The changelog does not state when the change took effect beyond the publication of the entry, and it does not provide migration tooling, pricing figures or a list of affected plan tiers. It also does not quantify how much additional origin egress or Class A usage a typical purge pattern would generate. Those gaps matter for anyone trying to estimate the cost impact before adjusting their caching workflow.

What the source does establish is the mechanism and the recommended alternative. Broad purges now behave like edge cache purges for Cache Reserve, the next request is a miss, the origin must serve the full response, and the rewrite is a Class A operation. The invalidate_cache endpoint and the dashboard Invalidate Cache control exist for teams that prefer revalidation, with the documented caveats about stale serving and Class A operations.

A reasonable editorial reading is that the change rewards narrower, more deliberate cache operations. Teams that previously relied on broad purges as a cheap refresh signal now have a documented reason to move those refreshes to invalidation, while keeping purges for cases where a guaranteed miss is actually wanted. That is analysis based on the documented behaviour, not a claim about Cloudflare's intent beyond the consistency rationale in the changelog.

The unresolved questions are operational rather than technical. How much a given purge pattern costs after the change depends on origin egress pricing, Cache Reserve Class A pricing and retention settings, none of which appear in the supplied material. The changelog also does not say whether the previous revalidation behaviour remains available through any other purge parameter, so teams should verify against current documentation before assuming a workaround exists.