# Cloudflare purge requests now force a Cache Reserve miss

Cloudflare changed how purges affect Cache Reserve: tag, hostname, prefix and everything purges now force a miss and a full origin fetch, while a new invalidate_cache endpoint keeps content in place for revalidation.

Canonical URL: https://freelancenews.online/news/cloudflare-purge-requests-now-force-a-cache-reserve-miss-e478ea80
Published: 2026-09-29T04:17:39.807Z
Updated: 2026-09-29T04:17:39.807Z
Source published: 2026-09-28T00:00:00.000Z
Event date: Not established
Review status: source-reviewed
Review method: Automated comparison against retrieved source text; not independent fact-checking.

## Report

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.

## Key points

- Purge requests now force a cache miss for Cache Reserve content regardless of purge type, applying to both API and dashboard requests.
- After a purge, the origin must deliver affected content in full even if unchanged, and Cloudflare rewrites it to Cache Reserve as a billed Class A operation.
- Broad purges by tag, hostname, prefix or everything do not immediately delete Cache Reserve content, which keeps incurring storage costs until replaced or expired.
- A new invalidate_cache endpoint, and Invalidate Cache in the dashboard, keeps content in Cache Reserve for revalidation; a 304 response avoids a full origin fetch but updating stored content is still a Class A operation.
- Invalidation can serve stale content while revalidating if cache settings allow, but only for edge cache copies, not content served from Cache Reserve.

## Practical implications — editorial interpretation

Editorial interpretation: freelancers and small teams that refresh assets with broad tag, hostname, prefix or everything purges should expect more origin traffic and additional Class A writes after this change, plus continued storage billing for the old copies. Moving routine refreshes to the invalidate_cache endpoint or the dashboard Invalidate Cache control is the documented way to keep revalidation behaviour, though it does not reduce Cache Reserve operations and can serve stale edge content when settings permit.

## Limitations and unknowns

The changelog does not state an effective date beyond the entry itself, does not give pricing figures or plan-tier scope, and does not quantify the extra origin egress or Class A usage a typical purge pattern would produce. It also does not say whether the previous revalidation behaviour remains reachable through any other purge parameter. No independent testing or third-party confirmation is included in the supplied evidence.

## Sources

- [1] developers.cloudflare.com: Changelog
  https://developers.cloudflare.com/changelog/post/2026-09-28-cache-reserve-purge-behavior/
  Retrieved: 2026-09-29T04:17:22.717Z

## Claim references

- Purge requests now force a cache miss for Cache Reserve content regardless of purge type, from both the API and the dashboard. [source 1]
- After a purge, the origin must deliver affected content in full even if unchanged, and Cloudflare rewrites it to Cache Reserve as a Class A operation. [source 1]
- Broad purges by tag, hostname, prefix or everything do not immediately delete Cache Reserve content, which keeps incurring storage costs until replaced or the retention period ends. [source 1]
- Cloudflare offers a new invalidate_cache endpoint, and the dashboard Invalidate Cache control on Caching > Configuration, to keep content in Cache Reserve and revalidate it. [source 1]
- With invalidation, a 304 Not Modified response lets Cloudflare reuse stored content, reducing origin egress but not Cache Reserve operations, and updating stored content is still a Class A operation. [source 1]
- Invalidation can serve stale content while revalidating if cache settings allow, but only for edge cache copies, not content served from Cache Reserve. [source 1]