Application Performance Updates & Release Notes

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.

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.

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.

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.

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.

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.

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.

Your origin can serve different responses for the same URL — different languages based on Accept-Language, or different formats based on Accept — by returning a Vary response header. Cloudflare's cache now honors that header directly in Cache Rules, so the same URL can hold multiple cached versions and each request is matched to the right one. Content that previously had to bypass cache to stay correct can now be cached, following standard HTTP caching behavior.

What changed

Your origin now decides which request headers matter by listing them in its Vary response, and you control how Cloudflare treats each one. When you have enabled Vary using a cache rule and a response includes a Vary header, the request headers listed become part of the cache key.

For each header your origin varies on, choose one of three actions:

Action
Behavior
Best for

• normalize
  Converts equivalent header values to the same cache key value before matching, collapsing redundant versions.
  Most Accept, Accept-Language, and Accept-Encoding use cases.

• passthrough
  Uses the raw header value to select the cached version and forwards it to the origin unchanged.
  When byte-for-byte differences in the header value should create versions.

• bypass
  Bypasses cache whenever this header name appears in the origin's Vary response.
  Per-user values, or headers with too many possible values to cache safely.

Benefits

Higher cache hit ratios: normalize treats semantically equivalent headers as one version. For example, Accept-Language: en-US, fr;q=0.8 and Accept-Language: fr;q=0.8, en-GB both resolve to the same cache key, so you serve more requests from cache instead of the origin.

Correct content negotiation: Requests always receive the cached version that matches their headers, so language and format variants stay accurate.

No origin or Worker changes required: If your origin already sends Vary, you configure the behavior entirely in Cache Rules.

Standards-aligned: Cache key calculation follows RFC 9111, and Vary: * continues to bypass cache as required by RFC 9110.

Availability

Vary in Cache Rules is available on all plans (Free, Pro, Business, and Enterprise). For per-request control in Workers subrequests, use the cf.vary property.

Get started

Configure Vary in the Cloudflare dashboard under Caching > Cache Rules, or through the Rulesets API. To learn how Vary affects cache keys and how each action works, refer to Vary and the Cache Rules Vary setting.

Cloudflare now accepts ML-DSA (FIPS 204) post-quantum certificates on the connection between Cloudflare's edge and your origin server. Combined with our existing X25519MLKEM768 key agreement, this lets you establish end-to-end post-quantum authentication on the Cloudflare-to-origin connection.

ML-DSA is supported in two origin-facing features:

Authenticated Origin Pulls (AOP) — upload an ML-DSA client certificate that Cloudflare will present during the mTLS handshake to your origin. Available at both zone-level and per-hostname scopes.

Custom Origin Trust Store (COTS) — upload an ML-DSA certificate authority that Cloudflare will trust when validating your origin server certificate under Full (strict) encryption mode.

Refer to Post-quantum signatures for certificate generation and setup guidance, and to PQC in Cloudflare products for the current post-quantum deployment status across Cloudflare.

Cloudflare now enforces DNS records quotas at the account level for Enterprise accounts. Instead of a per-zone limit, these accounts have a quota on the total number of records across all of their zones, letting you distribute records across your zones however you like — regardless of each zone's plan. Public and internal zones are counted separately, each with a default quota of 1,000,000 records.

Accounts without an account-level quota are unaffected: existing per-zone quotas behave exactly as before.

For more details, refer to DNS records quota.

What to expect in your analytics

Cloudflare now returns a BYPASS cache status whenever a response is not cacheable, instead of the previous mix of BYPASS and MISS that depended on why Cloudflare chose not to cache the response.

There are multiple reasons Cloudflare may refuse to cache a response — for example, the response exceeds the maximum cacheable file size for your plan, the origin sends Cache-Control: no-cache, private, or max-age=0, the response includes a Set-Cookie header, or the request includes an Authorization header.

Previously, only some of these conditions returned BYPASS. Others — such as responses exceeding the maximum cacheable file size — returned MISS on every request, regardless of whether Origin Cache Control was on or off. Because the response could never be cached, every subsequent request also returned MISS, which looked indistinguishable from a broken cache and made it hard to tell whether Cloudflare was trying and failing to cache the asset or had deliberately chosen not to cache it.

BYPASS now consistently signals that Cloudflare refused to cache the response, regardless of the reason. MISS is reserved for cacheable responses that simply were not in the local cache at request time.

After this change rolls out, you should see:

• MISS rate decreases: Uncacheable responses no longer count as cache misses.
• BYPASS rate increases: These same responses are now reported as bypasses.
• Cache hit ratio increases: Hit ratio calculations no longer include uncacheable traffic that could never have been cached, giving you a more accurate view of cache effectiveness.

Your total request volume and origin traffic are unchanged — only the cache status label is different.

Browser cache TTL behavior is preserved

The cache status label is the only thing changing — browser cache TTL handling for any given response is identical to what it was before:

• Responses that historically returned MISS because Cloudflare refused to cache them (for example, responses over the maximum cacheable file size) now return BYPASS, but continue to have browser cache TTL applied — exactly as they did when they were labeled MISS.
• Responses that historically returned BYPASS and skipped browser cache TTL continue to skip browser cache TTL.

In both cases, the decision to apply browser cache TTL depends on the underlying reason Cloudflare did not cache the response, not on the new BYPASS label.

Starting today, everyone can opt in to a refreshed DNS records page in the Cloudflare dashboard. Over the coming weeks, the new experience will become the default for Free plan users first, followed by paid plans.

What is new

Better table experience: resizable and hideable columns, row pinning, advanced filters with logical operators (AND/OR), configurable pagination, and expanded input fields so long values are no longer cut off.

First-class mobile experience: responsive layout with a touch-friendly, card-based UI and compact controls for small screens.

DNS quick reference: bite-sized explainers for DNS, proxy status, and TTL, available directly in the product to help users configure records without leaving the page.

Modern frontend: a refactor onto Cloudflare's new UI framework that improves performance and lays the foundation for future improvements.

Rollout plan

Dates are subject to change based on feedback received during the rollout.

20 May - 05 June: ramped rollout to Free, then Pro and Business plans.

08 June - 03 July: ramped rollout to Enterprise plans.

Share your feedback

Once the new experience is turned on for your account, look for the feedback link at the top of the DNS records page in the Cloudflare dashboard and let us know what you think. Your input helps us prioritize the next round of improvements.