Changelog

Every plan now gets at least 30 days of analytics data. Adaptive analytics datasets, such as HTTP requests, security events, and DNS analytics, retain at least 31 days of data for Free and Pro domains, and you can query up to 30 days in a single request. Previously, Free and Pro domains could see between 24 hours and 8 days of history depending on the dataset.

A full month of history lets you investigate an issue after it happens, compare today with the same day in previous weeks, and tell a one-time spike from a longer trend. The change applies in the Cloudflare dashboard, in Custom Dashboards, and through the GraphQL Analytics API.

Domain analytics also now live in one place. In the Cloudflare dashboard, select a domain and go to Analytics to see Traffic, Performance, Security, Cache, Origin, DNS, and Visitors as tabs that share one time range and one set of filters. Account-level analytics are under Observability > Analytics.

This change does not alter which datasets or fields your plan can access. Aggregated datasets, such as httpRequests1hGroups, keep their existing per-plan limits. To check the exact retention and query window for a zone or account, query the settings for each dataset.

For plan-specific limits, refer to Security Analytics, Security Events, and GraphQL Analytics API limits.

You can now build Custom Dashboards charts from Workers Observability data. Two new datasets, Workers Observability — Logs and Workers Observability — Traces (OTel), let you chart Worker invocations, log levels, errors, CPU and wall time, span counts, and durations next to HTTP traffic, security events, and other analytics datasets.

This gives you one dashboard for an application that spans Cloudflare's network and your Workers. For example, you can put request volume, WAF blocks, and Worker error rates on the same view, filter all three by time range, and spot whether a spike in errors lines up with a change in traffic.

The datasets are available for every Worker in your account that has Workers Logs or Workers Traces turned on. Custom Dashboards also now allow up to 100 dashboards for every account.

To get started, refer to Workers Observability data in Custom Dashboards.

Cloudflare has fixed an issue affecting WebSocket data transfer and session duration reporting. HTTP Traffic Analytics and HTTP request logs now correctly report data transferred throughout a WebSocket connection and the duration of the full session. During the affected period, reporting captured only the bytes and duration of the initial 101 Switching Protocols handshake for some WebSocket connections.

Customers with WebSocket traffic will see the correct Data Transfer in the dashboard and EdgeResponseBytes in analytics and HTTP request logs. Reported session duration now reflects the full WebSocket session rather than only the handshake. These changes restore the accounting of existing WebSocket traffic and duration. They do not indicate an increase in traffic or alter WebSocket connection behavior.

The separate WebSocket Analytics Logpush dataset continues to provide per-connection directional byte counts, timestamps, and close details.

For more information about HTTP Traffic Analytics, refer to Zone Analytics.

Custom Dashboards are now available to all Cloudflare customers. Build personalized views that highlight the metrics most critical to your infrastructure and security posture, moving beyond standard product dashboards.

This update significantly expands the data available for visualization. Build charts based on any of the 100+ datasets available via the Cloudflare GraphQL API, covering everything from WAF events and Workers metrics to Load Balancing and Zero Trust logs.

Log Explorer customers can select Log Explorer datasets to create charts from raw, unsampled log data.

• Unified visibility: Consolidate signals from different Cloudflare products (for example, HTTP Traffic and R2 Storage) into a single view.
• Flexible monitoring: Create charts that focus on specific status codes, ASN regions, or security actions that matter to your business.
• Expanded limits: Log Explorer customers can create up to 100 dashboards (up from 25 for standard customers).

To get started, refer to the Custom Dashboards documentation.

The Server-Timing header now includes a new cfWorker metric that measures time spent executing Cloudflare Workers, including any subrequests performed by the Worker. This helps developers accurately identify whether high Time to First Byte (TTFB) is caused by Worker processing or slow upstream dependencies.

Previously, Worker execution time was included in the edge metric, making it harder to identify true edge performance. The new cfWorker metric provides this visibility:

Server-Timing: cdn-cache; desc=DYNAMIC, edge; dur=20, origin; dur=100, cfWorker; dur=7

In this example, the edge took 20ms, the origin took 100ms, and the Worker added just 7ms of processing time.

The cfWorker metric is enabled by default if you have Real User Monitoring (RUM) enabled. Otherwise, you can enable it using Rules.

This metric is particularly useful for:

• Performance debugging: Quickly determine if latency is caused by Worker code, external API calls within Workers, or slow origins.
• Optimization targeting: Identify which component of your request path needs optimization.
• Real User Monitoring (RUM): Access detailed timing breakdowns directly from response headers for client-side analytics.

For more information about Server-Timing headers, refer to the W3C Server Timing specification ↗︎.

The cached/uncached classification logic used in Zone Overview analytics has been updated to improve accuracy.

Previously, requests were classified as "cached" based on an overly broad condition that included blocked 403 responses, Snippets requests, and other non-cache request types. This caused inflated cache hit ratios — in some cases showing near-100% cached — and affected approximately 15% of requests classified as cached in rollups.

The condition has been removed from the Zone Overview page. Cached/uncached classification now aligns with the heuristics used in HTTP Analytics, so only requests genuinely served from cache are counted as cached.

What changed:

• Zone Overview — Cache ratios now reflect actual cache performance.
• HTTP Analytics — No change. HTTP Analytics already used the correct classification logic.
• Historical data — This fix applies to new requests only. Previously logged data is not retroactively updated.

The GraphQL Analytics API now supports confidence intervals for sum and count fields on adaptive (sampled) datasets. Confidence intervals provide a statistical range around sampled results, helping verify accuracy and quantify uncertainty.

• Supported datasets: Adaptive (sampled) datasets only.
• Supported fields: All sum and count fields.
• Usage: The confidence level must be provided as a decimal between 0 and 1 (e.g. 0.90, 0.95, 0.99).
• Default: If no confidence level is specified, no intervals are returned.

For examples and more details, see the GraphQL Analytics API documentation.

We’ve launched two powerful new tools to make the GraphQL Analytics API more accessible:

The new GraphQL API Explorer ↗︎ helps you build, test, and run queries directly in your browser. Features include:

• In-browser schema documentation to browse available datasets and fields
• Interactive query editor with autocomplete and inline documentation
• A "Run in GraphQL API Explorer" button to execute example queries from our docs
• Seamless OAuth authentication — no manual setup required

MCP Servers let you use natural language tools like Claude to generate structured queries against your data. See our blog post ↗︎ for details on how they work and which servers are available. The new GraphQL MCP server ↗︎ helps you discover and generate useful queries for the GraphQL Analytics API. With this server, you can:

• Explore what data is available to query
• Generate and refine queries using natural language, with one-click links to run them in the API Explorer
• Build dashboards and visualizations from structured query outputs

Example prompts include:

• “Show me HTTP traffic for the last 7 days for example.com”
• “What GraphQL node returns firewall events?”
• “Can you generate a link to the Cloudflare GraphQL API Explorer with a pre-populated query and variables?”

We’re continuing to expand these tools, and your feedback helps shape what’s next. Explore the documentation to learn more and get started.