Application Performance Release Notes

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

Cloudflare Secrets Store integration with AI Gateway

Cloudflare Secrets Store is now integrated with AI Gateway, allowing you to store, manage, and deploy your AI provider keys in a secure and seamless configuration through Bring Your Own Key. Instead of passing your AI provider keys directly in every request header, you can centrally manage each key with Secrets Store and deploy in your gateway configuration using only a reference, rather than passing the value in plain text.

You can now create a secret directly from your AI Gateway in the dashboard by navigating into your gateway -> Provider Keys -> Add .

You can also create your secret with the newly available ai_gateway scope via wrangler, the Secrets Store dashboard, or the API .

Then, pass the key in the request header using its Secrets Store reference:
curl -X POST https://gateway.ai.cloudflare.com/v1//my-gateway/anthropic/v1/messages
--header 'cf-aig-authorization: ANTHROPIC_KEY_1
--header 'anthropic-version: 2023-06-01'
--header 'Content-Type: application/json'
--data '{"model": "claude-3-opus-20240229", "messages": [{"role": "user", "content": "What is Cloudflare?"}]}'

Or, using Javascript:
import Anthropic from '@anthropic-ai/sdk';

const anthropic = new Anthropic({
apiKey: "ANTHROPIC_KEY_1",
baseURL: "https://gateway.ai.cloudflare.com/v1//my-gateway/anthropic",
});

const message = await anthropic.messages.create({
model: 'claude-3-opus-20240229',
messages: [{role: "user", content: "What is Cloudflare?"}],
max_tokens: 1024
});

For more information, check out the blog !

Original source Report a problem

You can now create more granular, network-aware Custom Rules in Cloudflare Load Balancing using the Autonomous System Number (ASN) of an incoming request.

This allows you to steer traffic with greater precision based on the network source of a request. For example, you can route traffic from specific Internet Service Providers (ISPs) or enterprise customers to dedicated infrastructure, optimize performance, or enforce compliance by directing certain networks to preferred data centers.

To get started, create a Custom Rule in your Load Balancer and select AS Num from the Field dropdown.

Original source Report a problem

Cloudflare Load Balancing Monitors

Cloudflare Load Balancing Monitors support loading and applying settings for a specific zone to monitoring requests to origin endpoints. This feature has been migrated to new infrastructure to improve reliability, performance, and accuracy.

All zone monitors have been tested against the new infrastructure. There should be no change to health monitoring results of currently healthy and active pools. Newly created or re-enabled pools may need validation of their monitor zone settings before being introduced to service, especially regarding correct application of mTLS.

What you can expect:

• More reliable application of zone settings to monitoring requests, including
  • Authenticated Origin Pulls
  • Aegis Egress IP Pools
  • Argo Smart Routing
  • HTTP/2 to Origin
  • Improved support and bug fixes for retries, redirects, and proxied origin resolution
  • Improved performance and reliability of monitoring requests withing the Cloudflare network
  • Unrelated CDN or WAF configuration changes should have no risk of impact to pool health

Original source Report a problem

GraphQL example for account-level DNS analytics

Authoritative DNS analytics are now available on the account level via the Cloudflare GraphQL Analytics API.

This allows users to query DNS analytics across multiple zones in their account, by using the accounts filter.

Here is an example to retrieve the most recent DNS queries across all zones in your account that resulted in an NXDOMAIN response over a given time frame. Please replace a30f822fcd7c401984bf85d8f2a5111c with your actual account ID.

GraphQL example for account-level DNS analytics

query GetLatestNXDOMAINResponses {
  viewer {
    accounts(filter: {accountTag: "a30f822fcd7c401984bf85d8f2a5111c"}) {
      dnsAnalyticsAdaptive(filter: {date_geq: "2025-06-16", date_leq: "2025-06-18", responseCode: "NXDOMAIN"}, limit: 10000, orderBy: [datetime_DESC]) {
        zoneTag
        queryName
        responseCode
        queryType
        datetime
      }
    }
  }
}

To learn more and get started, refer to the DNS Analytics documentation.

Original source Report a problem

Participating beta testers can now fully configure Internal DNS directly in the Cloudflare dashboard.

Internal DNS enables customers to:

• Map internal hostnames to private IPs for services, devices, and applications not exposed to the public Internet
• Resolve internal DNS queries securely through Cloudflare Gateway
• Use split-horizon DNS to return different responses based on network context
• Consolidate internal and public DNS zones within a single management platform

What’s new in this release:

• Beta participants can now create and manage internal zones and views in the Cloudflare dashboard

Note

The Internal DNS beta is currently only available to Enterprise customers.

To learn more and get started, refer to the Internal DNS documentation.

Original source Report a problem