Application Performance Release Notes

Request body buffering

Controls how Cloudflare buffers HTTP request bodies before forwarding them to your origin server:

Mode Behavior Standard (default) Cloudflare can inspect a prefix of the request body for enabled functionality such as WAF and Bot Management. Full Buffers the entire request body before sending to origin. None No buffering — the request body streams directly to origin without inspection.

Response body buffering

Controls how Cloudflare buffers HTTP response bodies before forwarding them to the client:

Mode Behavior Standard (default) Cloudflare can inspect a prefix of the response body for enabled functionality. None No buffering — the response body streams directly to the client without inspection.

Setting body buffering to None may break security functionality that requires body inspection, including the Web Application Firewall (WAF) and Bot Management. Ensure that any paths where you disable buffering do not require security inspection.

These settings only take effect on zones running Cloudflare's latest CDN proxy. Enterprise customers can contact their account team to enable the latest proxy on their zones.

API example

{
  "action": "set_config",
  "action_parameters": {
    "request_body_buffering": "standard",
    "response_body_buffering": "none"
  }
}

For more information, refer to Configuration Rules.

Original source Report a problem

New functions

Function Description Availability encode_base64(input, flags) Encodes a string to Base64 format. Optional flags parameter: u for URL-safe encoding, p for padding (adds = characters to make the output length a multiple of 4, as required by some systems). By default, output is standard Base64 without padding. All plans (in header transform rules) sha256(input) Computes a SHA256 hash of the input string. Requires enablement

Note
The sha256() function is available as an Enterprise add-on and requires a specific entitlement. Contact your account team to enable it.

Examples

Encode a string to Base64 format:

encode_base64("hello world")

Returns: aGVsbG8gd29ybGQ

Encode a string to Base64 format with padding:

encode_base64("hello world", "p")

Returns: aGVsbG8gd29ybGQ=

Perform a URL-safe Base64 encoding of a string:

encode_base64("hello world", "u")

Returns: aGVsbG8gd29ybGQ

Compute the SHA256 hash of a secret token:

sha256("my-token")

Returns a hash that your origin can validate to authenticate requests.

Compute the SHA256 hash of a string and encode the result to Base64 format:

encode_base64(sha256("my-token"))

Combines hashing and encoding for systems that expect Base64-encoded signatures.

For more information, refer to the Functions reference.

Original source Report a problem

New functions

Function Description split(source, delimiter) Splits a string into an array of strings using the specified delimiter. join(array, delimiter) Joins an array of strings into a single string using the specified delimiter. has_key(map, key) Returns true if the specified key exists in the map. has_value(map, value) Returns true if the specified value exists in the map.

Example use cases

Check if a country code exists in a header list:

has_value(split(http.response.headers["x-allow-country"][0], ","), ip.src.country)

Check if a specific header key exists:

has_key(http.request.headers, "x-custom-header")

Join array values for logging or comparison:

join(http.request.headers.names, ", ")

For more information, refer to the
Functions reference.

Original source Report a problem

The ip.src.metro_code field in the Ruleset Engine is now populated with DMA (Designated Market Area) data.
You can use this field to build rules that target traffic based on geographic market areas, enabling more granular location-based policies for your applications.

Field details

Field Type Description ip.src.metro_code String null

Example filter expression:

ip.src.metro_code eq "501"

For more information, refer to the Fields reference.

Original source Report a problem

Audit logs for purge events

You can now review detailed audit logs for cache purge events, giving you visibility into what purge requests were sent, what they contained, and by whom. Audit your purge requests via the Dashboard or API for all purge methods:

• Purge everything
• List of prefixes
• List of tags
• List of hosts
• List of files

Example

The detailed audit payload is visible within the Cloudflare Dashboard (under Manage Account > Audit Logs ) and via the API. Below is an example of the Audit Logs v2 payload structure:

{
  "action": {
    "result": "success",
    "type": "create"
  },
  "actor": {
    "id": "1234567890abcdef",
    "email": "[email protected]",
    "type": "user"
  },
  "resource": {
    "product": "purge_cache",
    "request": {
      "files": [
        "https://example.com/images/logo.png",
        "https://example.com/css/styles.css"
      ]
    },
  },
  "zone": {
    "id": "023e105f4ecef8ad9ca31a8372d0c353",
    "name": "example.com"
  }
}

Get started

To get started, refer to the Audit Logs documentation.

Original source Report a problem

Example scenario

You can now see the exact cache key generated for any request directly in Cloudflare Trace. This visibility helps you troubleshoot cache hits and misses, and verify that your Custom Cache Keys 1 configured via Cache Rules or Page Rules 2 are working as intended.

Previously, diagnosing caching behavior required inferring the key from configuration settings. Now, you can confirm that your custom logic for headers, query strings, and device types is correctly applied.

Access Trace via the dashboard or API, either manually for ad-hoc debugging or automated as part of your quality-of-service monitoring.

If you have a Cache Rule that segments content based on a specific cookie (for example, user_region ), run a Trace with that cookie present to confirm the user_region value appears in the resulting cache key.

The Trace response includes the cache key in the cache object:

{
  "step_name": "request",
  "type": "cache",
  "matched": true,
  "public_name": "Cache Parameters",
  "cache": {
    "key": {
      "zone_id": "023e105f4ecef8ad9ca31a8372d0c353",
      "scheme": "https",
      "host": "example.com",
      "uri": "/images/hero.jpg"
    },
    "key_string": "023e105f4ecef8ad9ca31a8372d0c353::::https://example.com/images/hero.jpg:::::"
  }
}

Get started

To learn more, refer to the Trace documentation and our guide on Custom Cache Keys.

Original source Report a problem

Cloudflare now provides two new request fields in the Ruleset engine that let you make decisions based on whether a request used TCP and the measured TCP round-trip time between the client and Cloudflare. These fields help you understand protocol usage across your traffic and build policies that respond to network performance. For example, you can distinguish TCP from QUIC traffic or route high latency requests to alternative origins when needed.

New fields

Field Type Description cf.edge.client_tcp Boolean Indicates whether the request used TCP. A value of true means the client connected using TCP instead of QUIC. cf.timings.client_tcp_rtt_msec Number Reports the smoothed TCP round-trip time between the client and Cloudflare in milliseconds. For example, a value of 20 indicates roughly twenty milliseconds of RTT.

Example filter expression:

cf.edge.client_tcp && cf.timings.client_tcp_rtt_msec < 100

More information can be found in the Rules language fields reference.

Original source Report a problem

Cloudflare Load Balancing Monitor Groups

Cloudflare Load Balancing now supports Monitor Groups, a powerful new way to combine multiple health monitors into a single, logical group. This allows you to create sophisticated health checks that more accurately reflect the true availability of your applications by assessing multiple services at once.

With Monitor Groups, you can ensure that all critical components of an application are healthy before sending traffic to an origin pool, enabling smarter failover decisions and greater resilience. This feature is now available via the API for customers with an Enterprise Load Balancing subscription.

What you can do

• Combine Multiple Monitors: Group different health monitors (for example, HTTP, TCP) that check various application components, like a primary API gateway and a specific /login service.
• Isolate Monitors for Observation: Mark a monitor as "monitoring only" to receive alerts and data without it affecting a pool's health status or traffic steering. This is perfect for testing new checks or observing non-critical dependencies.
• Improve Steering Intelligence: Latency for Dynamic Steering is automatically averaged across all active monitors in a group, providing a more holistic view of an origin's performance.

This enhancement is ideal for complex, multi-service applications where the health of one component depends on another. By aggregating health signals, Monitor Groups provide a more accurate and comprehensive assessment of your application's true status.

For detailed information and API configuration guides, please visit our developer documentation for Monitor Groups.

Original source Report a problem

Access GraphQL-powered DNS Firewall analytics directly in the Cloudflare dashboard.

Explore Four Interactive Panels

• Query summary: Describes trends over time, segmented by dimensions.
• Query statistics: Describes totals, cached/uncached queries, and processing/response times.
• DNS queries by data center: Describes global view and the top 10 data centers.
• Top query statistics: Shows a breakdown by key dimensions, with search and expand options (up to top 100 items).

Additional features:

• Apply filters and time ranges once. Changes reflect across all panels.
• Filter by dimensions like query name, query type, cluster, data center, protocol (UDP/TCP), IP version, response code/reason, and more.
• Access up to 62 days of historical data with flexible intervals.

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 DNS Firewall
• Refer to the DNS Firewall Analytics to learn more.

Original source Report a problem

Smart Tiered Cache

now falls back to
Generic Tiered Cache
when the origin location cannot be determined, improving cache precision for your content.
Previously, when Smart Tiered Cache was unable to select the optimal upper tier (such as when origins are masked by Anycast IPs), latency could be negatively impacted. This fallback now uses Generic Tiered Cache instead, providing better performance and cache efficiency.

How it works

When Smart Tiered Cache falls back to Generic Tiered Cache:

• Multiple upper-tiers: Uses all of Cloudflare's global data centers as a network of upper-tiers instead of a single optimal location.
• Distributed cache requests: Lower-tier data centers can query any available upper-tier for cached content.
• Improved global coverage: Provides better cache hit ratios across geographically distributed visitors.
• Automatic fallback: Seamlessly transitions when origin location cannot be determined, such as with Anycast-masked origins.

Benefits

• Preserves high performance during fallback: Smart Tiered Cache now maintains strong cache efficiency even when optimal upper tier selection is not possible.
• Minimizes latency impact: Automatically uses Generic Tiered Cache topology to keep performance high when origin location cannot be determined.
• Seamless experience: No configuration changes or intervention required when fallback occurs.
• Improved resilience: Smart Tiered Cache remains effective across diverse origin infrastructure, including Anycast-masked origins.

Get started

This improvement is automatically applied to all zones using
Smart Tiered Cache
. No action is required on your part.

Original source Report a problem