Application Performance Updates & Release Notes

You can now invalidate cached content instead of purging it. Invalidation marks matching content as stale. On the next request, Cloudflare revalidates the content with your origin. If your origin responds with 304 Not Modified, Cloudflare reuses the cached content instead of downloading it again.

Use invalidation to refresh a group of assets when only some of them have changed. For example, invalidate all content that shares a cache tag. Cloudflare reuses unchanged assets instead of downloading them again. This requires your origin to return an ETag or Last-Modified header and support conditional requests.

Invalidation supports the same selectors as purge: URLs, cache tags, hostnames, URL prefixes, and everything. To invalidate content, send a POST request to the new invalidate_cache endpoint:

curl --request POST \
"https://api.cloudflare.com/client/v4/zones/$ZONE_ID/invalidate_cache" \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
--header "Content-Type: application/json" \
--data '{"tags":["product-images"]}'

In the dashboard, use Invalidate Cache on the Caching > Configuration page.

Your cache settings determine whether Cloudflare serves stale content while it revalidates. Cloudflare can also serve invalidated content stale if your origin returns a 5xx error or cannot be reached. To stop serving cached content, purge it instead.

Invalidation requests count toward the same rate limits as purge requests.

Purge behavior for Cache Reserve also changes with this release. For details, refer to Cache Reserve purge behavior.

For more information, refer to Invalidate cached content.

Original source

Purge requests now force a cache miss for Cache Reserve content, regardless of purge type. Previously, purging by cache tag, hostname, prefix, or everything marked matching Cache Reserve content for revalidation. Purging by URL already removed content from Cache Reserve and is unchanged.

This change applies to purge requests from the API and the dashboard. Cache Reserve now handles purges the same way as the edge cache.

Cost impact

After a purge, the next request for affected content is a Cache Reserve miss. Your origin must deliver the content in full, even if it has not changed. Cloudflare then writes the content to Cache Reserve again, which is billed as a Class A operation.

Purging by tag, hostname, prefix, or everything does not delete content from Cache Reserve right away. Matching content continues to incur storage costs until a later request replaces it or its retention period ends.

If you frequently purge Cache Reserve content by tag, hostname, prefix, or everything, review the effect on your origin egress and Cache Reserve usage.

Keep revalidating Cache Reserve content

To keep content in Cache Reserve and revalidate it instead, send the same request to the new invalidate_cache endpoint:

curl --request POST \
"https://api.cloudflare.com/client/v4/zones/$ZONE_ID/invalidate_cache" \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
--header "Content-Type: application/json" \
--data '{"tags":["product-images"]}'

In the dashboard, use Invalidate Cache on the Caching > Configuration page.

If your origin responds with 304 Not Modified, Cloudflare reuses the stored content instead of fetching it from your origin again. Compared with purging, invalidation reduces origin egress but not Cache Reserve operations. Updating the stored content after a 304 response is still a Class A operation. Invalidating by URL also updates the stored content when you send the request, which is a Class A operation.

Unlike the previous purge behavior, invalidation can serve stale content while it revalidates if your cache settings allow it. This applies only to copies in the edge cache, not to content served from Cache Reserve. Cloudflare can also serve invalidated content stale if your origin returns a 5xx error or cannot be reached. For details, refer to Invalidate cached content.

Original source

Cloudflare now displays warnings for shadowed records in all zones. A record is shadowed when a subdomain delegation gives authority for its name, or a name below it, to another set of nameservers. The record remains present, but your zone is not authoritative for it thus Cloudflare will not respond with it to matching DNS queries. These warnings help you find records that may no longer resolve from the expected zone.

Shadow metadata is also available in DNS records API responses when you set include_shadow_metadata=true. The metadata identifies the delegating NS records and, when applicable, whether an A or AAAA record is glue. For more information, refer to Shadowed records.

Original source

The Rulesets API now supports Origin Range Requests in Cache Rules.

This setting lets Cloudflare fetch large files from your origin in cache-aligned byte ranges. Cloudflare may expand a client range and issue several single-range origin requests.

Set origin_range_requests.mode to on, off, or default for any traffic matched by a Cache Rule.

To override Cloudflare's default Origin Range Requests behavior, set the mode to off. The following rule turns off generated origin range requests for all traffic without changing cache eligibility:

{
"expression": "true",
"action": "set_cache_settings",
"action_parameters": {
"origin_range_requests": {
"mode": "off"
}
}
}

Origin Range Requests do not make otherwise ineligible content cacheable. If your origin ignores Range and returns a complete 200 OK, Cloudflare can use the response but must download the complete file. Origins should honor Accept-Encoding: identity and return consistent, unencoded partial responses.

For configuration details and mode behavior, refer to Origin Range Requests in Cache Rules. For client responses and the complete origin contract, refer to Range request behavior.

Original source

Cloudflare Load Balancing now supports pool sets through the API. Pool sets combine geographic matching with location-specific traffic steering. One load balancer can now use different routing behavior for different locations.

Each pool set can match a Cloudflare data center, country, or region. It then supplies the candidate pools and can apply its own steering policy, pool weights, and fallback pool. Cloudflare evaluates pool sets in array order and applies the first matching pool set.

For example, this pool set uses Dynamic Latency steering for traffic from Germany:

{
  "pool_sets": [
    {
      "name": "germany-lowest-latency",
      "match": { "topology": { "countries": ["DE"] } },
      "overrides": {
        "pools": [
          "0930eec54a4c7ae6616985b79f678210",
          "c8b4f5a6d7e84910a2b3c4d5e6f70819"
        ],
        "steering_policy": "dynamic_latency"
      }
    }
  ]
}

Use pool sets for active-active traffic distribution, location-specific failover, and regional routing policies. For proxied traffic, a pool set can also return a fixed HTTP response instead of selecting a pool.

For configuration details and more examples, refer to Pool sets.

Original source

We fixed a regression where Automatic Platform Optimization (APO) stopped caching some HTML requests that did not send an explicit Accept: text/html header — commonly crawlers, bots, and uptime monitors. These requests were being served from your origin (cf-cache-status: DYNAMIC) instead of the cache.

APO now caches these requests again. No action is needed. If you added a Transform Rule to set Accept: text/html as a workaround, you can remove it.

For details on how APO decides what to cache, refer to About APO.

Original source

Cloudflare Web Analytics (Real User Monitoring) is rolling out accuracy improvements to client-side soft navigations. Update: this update is complete as of 2026-09-04.

This change may alter the volume of reported pageviews and visits in the dashboard and GraphQL API. The reported Largest Contentful Paint (LCP) metric may also fluctuate. The extent of these variances depend on your front-end architecture and visitor traffic patterns.

Single Page Applications (SPAs)—such as websites built with React, Angular, Vue, or Svelte—predominantly use soft navigations. Soft navigations avoid fully unloading the current page and rendering the next one from scratch as visitors navigate.

Any client-side navigation counts as a soft navigation, including navigations intercepted by the Navigation API ↗ or triggered by the History API ↗. This means a non-SPA website can have soft navigation activity if its implementation uses these APIs.

The main improvement comes from Google Chrome's new Soft Navigation API ↗. It natively measures Largest Contentful Paint (LCP) on soft navigations, removing a blind spot in perceived loading speed across pageviews.

We've extended our navigationType values to segment these different types of navigations:

navigationType

New? Description navigate ❌ Hard navigations that traditional websites (or "Multi Page Applications") perform when clicking links or submitting forms soft-navigation ✅ Where the new Soft Navigation API ↗ is available and a visitor makes a client-side navigation, we record these events routing-apis ✅ Where the native Soft Navigation API is unavailable (e.g. Safari, Firefox, older Chromium-based browsers), we fallback to measuring soft navigations using the Navigation API ↗ or History API ↗. We cannot collect LCP for these, but the other Core Web Vitals are present

Prior to this change, we only used History API and all navigations were bucketed into navigate.

For more information, refer to the Navigation Types and Web Analytics SPA documentation pages.

Original source

Load balancing analytics now filters traffic data by pool name instead of pool ID, aligning the query behavior with the pool names displayed in the filter dropdown.

Previously, the analytics pool filter queried by internal pool ID while displaying pool names in the UI dropdown. This mismatch caused filtering issues when pools shared similar names or when you expected results based on the visible pool name. Because the underlying query used a different identifier than what appeared on screen, the displayed data could be confusing or incorrect.

The pool filter now queries by the same pool name shown in the dropdown. When you select a pool from the filter, the analytics graphs and tables display data for that specific pool as you would expect. This change affects:

• Requests over time, filtering the chart series to the selected pool.
• Pool distribution, showing only the selected pool segment.
• Top endpoints, displaying cards for origins in the selected pool.
• Latency, showing latency data for the selected pool.

The Logs view and health event filtering are unchanged.

To use this, go to Traffic > Load Balancing Analytics for a zone. The same pool filter appears in the analytics view for an individual load balancer under Load Balancing at the account level.

For more information about analytics filters and metrics, refer to Load Balancing Analytics.

Original source

Load Balancing health notifications are now stateful. When a pool or endpoint becomes unhealthy, the notification opens an incident in your alerting tool as before. When that same pool or endpoint recovers, the follow-up notification is matched to the original alert and resolves that incident automatically, so you no longer have to close it by hand.

As part of this change, Load Balancing also sends a notification when a pool or endpoint returns to a healthy state, not only when it becomes unhealthy. Expect to see recovery notifications alongside the failure notifications you already receive.

This applies to your existing Load Balancing health alerts with no configuration change, and it matches the behavior already used by Health Checks notifications.

Two things to keep in mind:

• A recovery notification is matched to the earlier unhealthy notification for the same pool or endpoint. Renaming an endpoint while an incident is open prevents the match, so that incident stays open until you close it.

• If a health change cannot be classified as either healthy or unhealthy, the notification is still delivered, but without the state needed to open or resolve an incident.

Refer to Integrate with PagerDuty to learn more about routing Load Balancing health notifications to an incident management tool.

Original source

Load balancing analytics now shows traffic served by your fallback pool separately from traffic routed to the same pool by normal steering.

Previously, requests were grouped by pool name alone. If the pool acting as your fallback also received traffic through your steering policy, both appeared as a single series, so it was not obvious from the graph whether Cloudflare was still making health-based routing decisions or had fallen back to the pool of last resort. Because the fallback pool ignores health, that distinction matters when you are diagnosing an outage or reviewing how much traffic was shed.

Fallback traffic is now labeled with the pool name followed by (Fallback). A pool named eu-west, for example, is shown as eu-west (Fallback). This label appears as its own entry in:

• Requests over time, as a separate series in the chart.
• Pool distribution, as a separate segment.
• Top endpoints, as a separate card for the pool.

The Latency view and the health event Logs are unchanged.

To see this, go to Traffic > Load Balancing Analytics for a zone. The same breakdown appears in the analytics view for an individual load balancer under Load Balancing at the account level.

Refer to load balancing analytics to learn more.

Original source

Cloudflare now takes the guesswork out of TLS 1.3 key agreement with your origins. Automatic key exchange predicts the preferred algorithm and sends its key share in the first ClientHello, helping avoid a HelloRetryRequest and one extra network round trip.

Automatic key exchange is on for all existing zones and on by default for new zones. When an origin supports both classical and post-quantum key agreements, Cloudflare prefers the post-quantum X25519MLKEM768 hybrid key agreement.

To change this behavior, go to SSL/TLS > Overview > Origin connection & post-quantum encryption. Turn off Automatic key exchange to stop automatic scans and preference updates. Turning it off does not change your compliance requirements.

Compliance requirements apply only to TLS 1.3 connections. The Post-quantum hybrid option requires hybrid post-quantum key agreements support on your origin server. The Federal Information Processing Standards (FIPS) option requires FIPS-compliant key agreements. Select both to require key agreements that satisfy both, or leave both unselected to allow all supported key agreements.

For requirements, configuration options, and rollout details, refer to Automatic key exchange to origins.

Original source

Internal DNS is now generally available. Internal DNS provides authoritative and recursive DNS for private networks on the same global network and control plane you already use for public DNS, Zero Trust, and application services.

Why it matters

Consolidate DNS operations. Public and private DNS run on one platform, with one API, one audit trail, and one place to set policy.

Simplify split-horizon DNS. Internal and external resolution are defined as separate views over shared zones, managed from a single control plane — so there is no drift to chase down.

Extend Zero Trust to DNS. Resolver policies decide which users and devices resolve against which view, enforced by the same Gateway that already governs the rest of your traffic.

Setting up Internal DNS takes three steps: create a zone, create a view, and define a resolver policy.

POST /zones
{
  "account": {
    "id": "<ACCOUNT_ID>"
  },
  "name": "corp.internal",
  "type": "internal"
}

Internal DNS is included with Cloudflare Gateway for Enterprise customers. To get started, refer to the Internal DNS documentation.

Original source

Cloudflare Web Analytics (Real User Monitoring) has rolled out performance optimizations to significantly improve the stability and loading speed of account-wide dashboards.

For larger accounts (with >100 Web Analytics sites), loading the aggregate account-wide view would often fail, running into timeouts or unexpected interface errors due to the massive scale of parallel query processing. This update optimizes how high-volume multi-site data is queried to reduce errors and provide a snappier dashboard experience.

Accounts with up to 1,000 sites will now be able to load this account-wide aggregate view without experiencing misleading errors.

If you have an account with over 1,000 sites, we cannot currently aggregate over this volume due to processing constraints but you will now be presented with a clear error and instruction to filter to the relevant site(s) you wish to see the data for.

Original source

The DNS Firewall page in the Cloudflare dashboard has been refreshed, bringing several settings that were previously API-only into the UI and modernizing how you view and manage your DNS Firewall clusters.

What is new

• More settings in the dashboard: cluster options that were previously only configurable through the API — such as attack mitigation, rate limiting, negative TTL, and resolver subnet — are now available directly in the dashboard.
• Better table experience: the DNS Firewall cluster table has been revised to surface cluster details at a glance, with resizable columns and the option to show or hide columns to tailor the view to your workflow.
• New create and edit UX: adding and editing clusters now uses a modernized form that groups related settings together, making configuration faster and clearer.

Availability

Available to all DNS Firewall customers as part of their existing subscription.

Where to find it

In the Cloudflare dashboard, go to the DNS Firewall page.

Go to Clusters

For more information, refer to DNS Firewall.

Original source