Changelog

The Core Web Vitals tell you whether a page is slow but beyond perceived load time, layout instability, or responsiveness they do not guide you to the problematic area directly. To help you with this, Real User Monitoring (RUM) in Web Analytics now breaks Largest Contentful Paint (LCP) and Interaction to Next Paint (INP) into their respective sub-parts. It also splits connection time into TCP and TLS. You can see this visualised in the dashboard or query it through the GraphQL Analytics API.

LCP is broken into four phases, so you can see which one is impacting your perceived load time:

1. Time to First Byte: how long the browser waits for the HTML document (timeToFirstByte in GraphQL).
2. Resource load delay: how long the browser takes to discover the LCP resource after the document starts arriving (lcpResourceLoadDelay).
3. Resource load duration: how long it takes to download that resource (lcpResourceLoadTime).
4. Element render delay: the gap between the resource arriving and the element appearing on screen (lcpElementRenderDelay).

You do not have to remember all this detail, there are tooltips available to guide you next to each sub-part metric in the dashboard.

INP is broken into three phases, guiding you to the area slowing down responsiveness:

1. Input delay: how long an interaction (click, tap or key press) is blocked before it can be processed (inpInputDelay).
2. Processing duration: how long your event handlers take to run (inpProcessingDuration).
3. Presentation delay: how long the browser takes to render the next frame after the handlers finish (inpPresentationDelay).

The page load timing breakdown now separates connection setup from the TLS handshake, so you can tell a slow network path from a slow TLS negotiation:

• Connection time (excluding TLS) (connectionTimeWithoutTLS)
• TLS handshake time: (tlsTime).

Note: we've retained connectionTime in the GraphQL API so you can still analyze the combined time.

The sub-parts are available on rumWebVitalsEventsAdaptiveGroups as percentiles, for example: lcpResourceLoadDelayP50 or inpInputDelayP50. The connection split is available on rumPerformanceEventsAdaptiveGroups as connectionTimeWithoutTLSP50 and tlsTimeP50, and so on for the other percentiles.

The percentiles available are: P25, P50, P75, P90, P95, P99, P999. All values are in microseconds. A negative value means the data is not available.

Head to the 'Core Web Vitals' section, here you can scroll down the report to see the sub-parts. The 'Page Load' section contains the Connection and TLS negotiation durations.

For more on the data, refer to the Web Analytics docs and the GraphQL Analytics API docs.

Log Explorer datasets are now queried from the Logs page under Observability in the Cloudflare dashboard. The Logs page brings Log Explorer and Workers Observability datasets together with a shared filter builder, SQL editor, and visualizations.

As part of this change, the Log Explorer menu is no longer shown in the dashboard navigation.

• Your enabled datasets, saved queries, and SQL queries continue to work on the Logs page.
• To manage datasets, open the dataset selector on the Logs page and select Configure next to the Log Explorer datasets.
• The previous Log Search page remains available at its direct URL.

For more information, refer to Log Search and the Logs overview.

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 Logpush is now available on Free, Pro, Business, and Enterprise plans with usage-based pricing. Free, Pro, and Business customers can enable Logpush through self-service. Enterprise customers continue to work with their account team. Logpush Transformers are also now generally available.

Each account receives included monthly usage before charges apply:

• Internal exports: 25 GB per month, then $0.03 per additional GB.
• External exports: 25 GB per month, then $0.10 per additional GB.
• Transformations: 1 GB per month, then $0.04 per additional GB.

R2 and Pipelines use the internal destination rate. All other destinations use the external destination rate.

Existing Enterprise contracts retain their current Logpush pricing through renewal. Workers Logpush for Workers Trace Events retains request-based pricing, and OpenTelemetry destinations retain event-based Workers Observability pricing.

For complete rates, measurement details, and billing examples, refer to Logpush pricing.

Transformers are now generally available for supported Logpush datasets on Free, Pro, Business, and Enterprise plans. Use SQL to filter records, reshape fields, redact sensitive values, compute new fields, or add metadata before Logpush delivers each batch.

Create and preview Transformers in Transformer Studio or through the Cloudflare API, then attach them to eligible account-scoped or zone-scoped Logpush jobs that use NDJSON output. Cloudflare validates each query against the dataset schema before saving it.

Each account includes 1 GB of transformation input per month. Additional input costs $0.04 per GB. For setup instructions, supported SQL, limits, and examples, refer to Transformers. For billing details, refer to Logpush pricing.

Logpush jobs can now exclude identified distributed denial-of-service (DDoS) attack traffic. This option reduces attack traffic in delivered logs.

It supports the http_requests, firewall_events, and network_analytics_logs datasets.

In the dashboard, select Exclude DDoS attack traffic under Advanced Options. With the API, add this field to a job request:

{
	"filter_attack_traffic": true
}

For more information, refer to API configuration.

Cloudflare Radar search now includes Internet events and outages alongside existing results. Search event descriptions or related entities, such as locations, ASes, bots, and top-level domains, to find relevant events and open the most relevant Radar view.

Event links preserve the event date range, making it easier to investigate what changed before, during, and after an event. These results are also available to browser-based AI agents through WebMCP.

Log Explorer has a refreshed dataset configuration experience in the Cloudflare dashboard. The new controls make it easier to choose which fields and events Log Explorer ingests.

• Grouped field selection organizes fields by category and shows the number selected in each group.
• Field details identify each field's data type and mark required or deprecated fields.
• Bulk controls let you select all fields or reset the selection to the dataset defaults.
• Ingestion filters let you ingest all events or only events that match your conditions.

These controls are available when you add a dataset or select Actions > Edit for an enabled dataset.

For more information, refer to Configure fields and filters.

Cloudflare Log Explorer customers can now permanently delete account and zone datasets from the Cloudflare dashboard or API.

Deletion protection is enabled by default to prevent accidental data loss. In the dashboard, go to Manage datasets, disable deletion protection for the dataset, select Delete, and enter the dataset name to confirm.

To delete a dataset through the API, first set deletion_protection to false with the Update an account or zone dataset method. Then use the Delete an account or zone dataset method.

Dataset deletion is irreversible and runs asynchronously. You cannot recreate the same dataset while deletion is in progress.

Cloudflare Enterprise customers using the Azure Functions-based Microsoft Sentinel connector ↗︎ must migrate to the Cloudflare for Microsoft Sentinel Codeless Connector Framework (CCF) connector ↗︎ by 2026-09-14.

Microsoft is deprecating the Azure Monitor HTTP Data Collector API. Support for the API ends on 2026-09-14. As a result, Cloudflare will no longer maintain the Azure Functions-based connector after that date.

To migrate, follow the Microsoft Sentinel integration setup guide.

• Download Cloudflare's CCF Sentinel Solution ↗︎
• Microsoft Sentinel data lake overview ↗︎
• About the CCF platform ↗︎

For more information, refer to Microsoft's Azure Monitor HTTP Data Collector API deprecation notice ↗︎.

Cloudflare Radar expands the Radar Researcher ↗︎ beta with richer sources and new ways to investigate Internet data.

Radar Researcher responses can now link to relevant Radar pages, reports, and Cloudflare Blog posts.

Select Explain with AI on a URL Scanner report ↗︎ to have Radar Researcher explain its findings and answer follow-up questions about the scanned site.

Shared conversations now open in fullscreen, while the share URL remains available until you close the panel or start a new conversation.

Open Radar Researcher ↗︎ to explore these improvements.

Radar adds an ASPA validation tool ↗︎ to its Routing section ↗︎. Enter a BGP AS_PATH and the tool checks it against the Autonomous System Provider Authorization (ASPA) ↗︎ records currently published in the RPKI, returning a verdict of Valid, Invalid, or Unknown. An Invalid verdict means no chain of provider authorizations covers the whole path, which is the signature of a route leak.

Validation follows draft-ietf-sidrops-aspa-verification ↗︎, so verdicts match those produced by validators implementing the same draft. The draft is still a work in progress and not yet an RFC.

Paths are read in BGP wire order: the rightmost AS is the origin, and the leftmost AS is the one closest to the collector or router that observed the route. AS numbers can be separated by spaces, commas, or hyphens, with or without an AS prefix. The full ASPA snapshot is loaded into the browser once, so the verdict, graph, and trace update as the path is edited, with no further requests. A set of example paths covers the interesting cases, including a route leak with an AS0 ASPA, where an AS declares that it has no providers at all.

The draft defines two verification algorithms that differ only in whether a down-ramp is permitted:

• Upstream (section 5.4 ↗︎) — for routes received from a customer, peer, route server client, or route server. Only an up-ramp is permitted.
• Downstream (section 5.5 ↗︎) — for routes received from a provider. Both an up-ramp and a down-ramp are permitted.

An up-ramp is the run of consecutive customer-to-provider hops from the origin to the apex of the path, and a down-ramp is the equivalent run from the announcing neighbor back to that apex. The tool evaluates both algorithms at once and labels each with its verdict, so a path that is legitimate when received from one session type and a leak when received from another is visible without switching modes. Selecting an algorithm drives the graph and the trace.

The ASPA validation graph draws the path hop by hop, labeling each AS with its role, whether it publishes an ASPA, and how many providers that ASPA authorizes. Every hop is marked Provider+, Not Provider+, or No attestation, and the maximum and minimum bounds of each ramp are drawn against the length of the path. Hops that no ramp reaches are highlighted, because a path the ramps cannot cover end to end is Invalid. The accompanying ASPA records table lists every AS in the path with its ASPA status and its authorized providers, each linked to its Radar AS page.

The Algorithm step by step section shows the derivation rather than just the answer. Two columns run the same scans under different stopping rules: the upper bounds, which test for Invalid and stop only on Not Provider+, and the lower bounds, which test for Unknown and also stop on No Attestation. A hop is Not Provider+ when the AS publishes an ASPA that does not list the next AS as a provider, and No Attestation when the AS publishes no ASPA at all. Each column lists the outcome for every hop scanned, marks where the scan stopped, gives the resulting ramp length, and then evaluates the verdict rule with the numbers filled in.

The path and the selected algorithm are kept in the URL, so a link reproduces a result exactly — for example, this route leak with an AS0 ASPA ↗︎. Appending &mode=upstream pins the link to the upstream algorithm. The graph is a standard Radar widget, so it can also be embedded or shared as an image.

The records behind the tool are the same ones served by the /bgp/rpki/aspa/snapshot endpoint of the ASPA API, and the number of records loaded and the snapshot timestamp are shown alongside the input.

Try the ASPA validation tool ↗︎ with a path of your own.

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:

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.

Cloudflare has updated Logpush datasets:

• Account Abuse Protection Events: A new dataset with fields including AuthenticationIdentityProvider, AuthenticationMethod, AuthenticationStatus, BotScore, ClientASN, ClientCity, ClientCountry, ClientIP, Email, EphemeralID, EventSource, EventType, FraudEmailRisk, Host, JA4, RayID, Timestamp, UserAgent, and UserID.
• Magic BGP Logs: A new dataset with fields including Direction, EventData, EventKind, EventTimestamp, TunnelID, and TunnelName.

• Firewall events (added): AISecurityCustomTopicCategories, WAFRequestSignatureCategories, and WAFRequestSignatureRefs.
• Gateway HTTP (added): ExperimentalFeatures and PackageInfo.
• HTTP requests (added): AISecurityCustomTopicCategories, ClientTLSKeyExchangeGroup, WAFRequestSignatureCategories, and WAFRequestSignatureRefs.

For the complete field definitions for each dataset, refer to Logpush datasets.

Cloudflare Radar ↗︎ publishes global statistics on post-quantum key agreement adoption across all Cloudflare traffic, but until now customers had no way to see the same measurement scoped to their own zones. This is now possible because the http_requests Logpush dataset — also queryable in Log Explorer — includes a new ClientTLSKeyExchangeGroup field.

The field reports the TLS key exchange group negotiated on the client-to-Cloudflare connection, by group name. Post-quantum connections appear as X25519MLKEM768, and classical connections appear as X25519, P-256, or another named group. A value of UNK means the group could not be determined, and NONE means either RSA key exchange was used or TLS was not used.

With this field, you can build per-zone reports showing what percentage of your inbound HTTPS traffic is protected by post-quantum key agreement, break the number down by hostname, path, user agent, or country, and push the data into your SIEM via any Logpush destination.

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.

Radar expands its Routing section ↗︎ with two widgets on AS pages, such as AS13335 ↗︎, that describe how a network reaches the rest of the Internet: the paths it takes toward the Tier-1 ↗︎ networks, and the mix of direct upstreams carrying its routes. Both are derived from RouteViews ↗︎ RIB snapshots, unioned across selected collectors.

The AS-level connectivity graph aggregates the BGP paths an AS uses to reach the Tier-1 networks, unioned across all the prefixes it announces, as observed by selected RouteViews collectors. It reads from left to right, starting at the queried AS and ending at the Tier-1 networks, and each node is labeled with its AS number, country, and organization name. Tier-1 nodes are marked so they stand apart from the intermediate networks that lead to them.

By default, the graph shows the network's direct connections to Tier-1 networks plus the indirect paths, which keeps the view readable. A Show full paths toggle expands it to every observed path, including transit through Tier-1 networks the AS already connects to. An IP version selector switches between IPv4 and IPv6, because the paths reaching Tier-1 networks may differ between the two address families.

This is the AS-level counterpart to the Real-time connectivity graph on prefix pages, such as the one for 1.1.1.0/24 ↗︎. Instead of covering a single prefix, it covers the union of paths for all prefixes an AS announces, which makes it a fast way to read a network's transit hierarchy: which providers it depends on, how many hops separate it from the core, and whether its paths to the core are diverse or concentrated. For more information on the prefix-level graph, refer to BGP real-time routes.

The Upstream providers widget tracks the share of an AS's observed paths carried by each of its direct upstream networks over time, drawn as a stacked area chart. Up to 10 upstreams appear as their own series and the remaining ones are grouped into Other. Transit changes such as adding a provider, dropping one, or moving traffic between them appear as movement between bands rather than as a single aggregate number. As with the connectivity graph, an IP version selector switches between IPv4 and IPv6.

The data behind both widgets is also available through two new endpoints on the BGP API:

• /bgp/routes/paths/{asn} — Returns the ordered AS path segments an AS uses to reach the Tier-1 networks, each with its observed path count, peer count, and contributing collectors, alongside the name and country of every ASN in the response. Pass collector to scope the result to a single RouteViews collector.
• /bgp/routes/upstreams/{asn}/timeseries — Returns the share of an AS's observed paths carried by each direct upstream over time. Use limit to control how many upstreams come back as separate series before the rest are grouped into an OTHER series, and ipVersion to select the address family.

Visit the AS13335 routing page ↗︎ to explore both widgets, or swap in any other AS number.

Cloudflare Radar now includes Radar Researcher ↗︎, a beta AI-powered assistant for exploring Internet trends and traffic data in plain language. Open Researcher from the header on any Radar page to ask questions by voice or text, receive explanations, and view interactive charts based on Radar API data.

To ask about a specific chart, select Explain with AI to start a conversation with its underlying data and context.

You can explore further with suggested follow-up questions, find earlier conversations through searchable history, and share conversations through shareable links.

Alongside the user-facing Researcher experience, Radar now supports WebMCP, allowing browser-based AI agents to navigate Radar, search data, and use tools such as URL scanning and domain lookup.

To get started, visit Cloudflare Radar ↗︎.

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.

Digital Experience Monitoring (DEX) provides visibility into device, network, and application performance across your Cloudflare SASE deployment.

The Device Monitoring page now analyzes hardware and network data between a Cloudflare One Client device and Cloudflare's edge, so you can diagnose connectivity and performance issues. Previously, this data was only available in raw DEX Device State Event logs, which required you to build your own analytics to interpret it.

A summary at the top of the page shows the health of each category at a glance, using Good, Fair, and Poor labels:

• Connection — connection status, Cloudflare One Client mode, and tunnel type over time
• Wi-Fi signal strength — signal measured in dBm over time, with thresholds that flag a weak signal
• Traffic performance — upstream and downstream performance, including network throughput on the active interface
• Device health — hardware metrics such as CPU, memory, and disk

You can filter by category and adjust the time range to correlate a device's metrics with a user's reported issue.

These analytics are available to all Cloudflare One customers at no additional cost.

To learn more, refer to the DEX monitoring documentation.

Enterprise customers can now push per-connection WebSocket analytics to any Logpush destination using the new websocket_analytics dataset. Each log record is emitted when a WebSocket connection closes and includes fields that were previously only available to Cloudflare engineers via internal tooling.

Key fields include:

• ConnectionCloseReason — why the connection ended: peerReset, peerNoError, timedOut, upstreamReset, protocolViolation, unspecifiedError, or none.
• ConnectionCloseSource — which side initiated the close: upstream, downstream, me, or both.
• ConnectionTransportCloseCode — the TLS alert code or TCP-level close code for additional precision.
• RayID — correlate WebSocket connection events with your existing HTTP Request logs.

The dataset also includes directional byte counts (BytesSentClient, BytesReceivedClient, BytesSentOrigin, BytesReceivedOrigin), connection timestamps, client IP, colo code, and request metadata from the original WebSocket upgrade.

This data lets you build alerts on connection close patterns — for example, detecting spikes in TCP resets (ConnectionCloseReason == "peerReset") grouped by host and data center — directly in your existing log analysis tools.

For the full list of available fields, refer to WebSocket Analytics.

Cloudflare has updated Logpush datasets:

• Gateway DNS (added): AppliedMaxTTL and UpstreamRecordTTLs.
• Gateway HTTP (added): Warnings.
• HTTP requests (added): CacheLockWaitedMs.

For the complete field definitions for each dataset, refer to Logpush datasets.

Cloudflare Logpush now supports firewall events as an account-scoped dataset. Configure a single Logpush job at the account level to receive firewall events for every zone in the account, instead of creating and maintaining a separate job per zone.

The dataset includes a new ZoneName field so you can identify which zone each event came from when consuming logs in your downstream pipeline.

• A new account-scoped firewall_events dataset, configurable via the Logpush API or the Cloudflare dashboard.
• The same fields and filter expressions supported by the existing zone-scoped firewall events dataset, plus the new ZoneName field.
• Support for all existing Logpush destinations.

Cloudflare has updated Logpush datasets:

• WebSocket Analytics: A new dataset with fields including BytesReceivedClient, BytesReceivedOrigin, BytesSentClient, BytesSentOrigin, ClientASN, ClientIP, ClientRequestHost, ClientRequestPath, ClientRequestUserAgent, ColoCode, ConnectionCloseReason, ConnectionCloseSource, ConnectionID, ConnectionTransportCloseCode, EdgeEndTimestamp, EdgeStartTimestamp, and RayID.

• Firewall events (added): ZoneName. The Firewall events dataset is now also available for account-scope Logpush, in addition to the existing zone scope.
• Email Security Alerts (added): BCC, DKIMResult, DMARCPolicy, DMARCResult, and SPFResult.

For the complete field definitions for each dataset, refer to Logpush datasets.