Changelog

Cloudflare Web Analytics (Real User Monitoring) is rolling out accuracy improvements to client-side soft navigations.

This change may alter the volume of pageviews reported in the dashboard and GraphQL API, though the extent depends 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 fixed an issue affecting WebSocket data transfer reporting. HTTP Traffic Analytics and HTTP request logs now correctly count data transferred throughout a WebSocket connection, restoring the correct behavior. During the affected period, reporting captured only the initial 101 Switching Protocols handshake for some WebSocket connections, which could underreport their data transfer.

Customers with WebSocket traffic will see the correct Data Transfer in the dashboard and EdgeResponseBytes in analytics and HTTP request logs. The change reflects restored accounting of existing WebSocket traffic, not an increase in traffic caused by this change. WebSocket connection behavior is unaffected.

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.

Radar now plots your IPv4 and IPv6 locations on the IP page ↗, shows the Cloudflare data centers serving your connection, and includes more detail about the autonomous system (AS) your primary IP belongs to.

The map of your connection now shows:

• IP location markers — The primary IP will show as a red marker. When both IP addresses do not geolocate to the same place, a second marker will appear in blue with a note explaining why IPv4 and IPv6 can resolve to different locations.
• Cloudflare data center markers — Cloudflare data centers now show as orange dots on the map and the one you are connected to is highlighted.
• Data center connectors — Each line connects your IP markers to their respective data centers.

Due to the data policies of our geolocation provider, this detailed location is only available for your own IP. Other IP addresses keep the current country-level view.

The AS card on the IP page now shows additional detail about the network an IP belongs to — including alternate names, the operator website, and an estimate of the AS user population — alongside the AS number and country.

Visit the Cloudflare Radar IP page ↗ to explore more details about your IP.

Regional Services now supports Regionalized IP Bindings, letting you regionalize traffic at the IP layer for prefixes you bring to Cloudflare through Bring Your Own IP (BYOIP).

Where Regional Hostnames regionalize traffic by hostname, Regionalized IP Bindings let you bind a CIDR from one of your prefixes to a region — ideal for address-map deployments and any service you address by IP rather than hostname. Cloudflare then terminates TLS and processes traffic to those addresses only within the data centers in that region.

Regionalized IP Bindings requires the Regional Services and Regional Services for BYOIP entitlements. Contact your account team to enable them.

To get started, refer to Regionalized IP Bindings.

Radar has changed how it measures Workers AI model and task popularity.

Previously, popularity was based on the number of unique accounts running inferences against each model or task. It is now based on the number of inferences, giving a more representative view of actual usage volume. This change will affect all new measurements as well as historical data. As a result, the model and task distributions shown on Radar may differ from what you saw previously, and historical trends may shift accordingly.

The Workers AI model popularity ↗ chart shows the distribution of inferences across models.

The Workers AI task popularity ↗ chart shows the distribution of inferences across tasks.

The same data is available via the following API endpoints:

• /ai/inference/summary/{dimension}
• /ai/inference/timeseries_groups/{dimension}

Explore the data on the AI Insights page ↗.

TL;DR: Brand Protection now features an Automated Cease & Desist (C&D) workflow. When you discover an infringing domain hosted outside of Cloudflare, you can instantly generate, review, and download a custom-branded, pre-filled legal notice in seconds.

This update introduces a major shift from pure detection to actionable enforcement, eliminating the manual burden for your Trust & Safety and Legal teams:

• Instant WHOIS and Recipient Lookup: We automatically scrape registrar data and WHOIS contact information (such as the registrant or registrar abuse email) behind the scenes, highlighting exactly where your notice needs to be sent
• Smart Template Automation: We pre-fill your custom-branded templates with essential metadata, including the infringing domain, registrar name, and discovery date.
• Tailored Enforcement Tones: Choose from three default layout strategies depending on the severity of the infrastructure match:
  • Exact Match: A formal demand for identical trademark infringements
  • Similar Match: A standard notice optimized for typosquatting (one-character distance matches)
  • Friendly Tone: An amicable initial outreach for potential unintentional or accidental infringements
• Full Editing Control: Before creating the final PDF, a real-time review screen allows you to fine-tune the messaging, modify placeholders, and ensure your text aligns perfectly with internal legal standards

When reviewing a malicious domain match inside your dashboard, your enforcement path splits depending on where the attacker is located:

1. On the Cloudflare Network: If the domain uses Cloudflare’s network or registrar, trigger our existing integrated abuse reporting flow with one click.
2. Hosted Elsewhere: If the domain is hosted on an external provider, click the Generate C&D Letter option to launch the new document builder, pick your template, verify the auto-populated recipient data, and download your finalized PDF.

You can manage your templates and enforce matches by going to the Cloudflare Dashboard > Application Security > Brand Protection and selecting your detected Brand Protection matches. For more information, read the Brand Protection documentation.

Note: Cloudflare does not represent you and cannot provide you with legal advice. Only you can decide whether your rights have been infringed, whether a cease and desist letter is appropriate, and what that letter should say.

Cloudforce One users can now turn Threat Events indicators into active defense. With this update, users can instantly generate a WAF rule that matches the dynamic list of IP addresses returned by any of their Saved Views.

Threat intelligence is most effective when it is immediately actionable. Previously, blocking threat actors required manually extracting indicators from threat events and copying them into your firewall rules. This new integration bridges the gap between threat discovery and threat mitigation:

• When you identify an active threat pattern - such as an ongoing campaign targeting a specific industry, or using a known indicator type - you can pivot from investigation to mitigation in a single click.
• Instead of writing complex, static IP rules, this functionality allows you to leverage the specific filtering logic you have already defined and saved within your Threat Events ecosystem.
• Automating the generation of the WAF rule expression from your threat views eliminates manual copying errors, ensuring that the right malicious infrastructure is blocked instantly.

You can implement these rules through both the dashboard UI and via the API / Terraform.

Go to Cloudflare Dashboard > Application Security > Threat Intelligence > Manage Views, select your desired view, and select Create WAF Rule.

This will automatically pre-populate the WAF rule builder with the matching threat event IP indicators.

You can also automate this workflow by utilizing the WAF Rule Builder API alongside your Threat Events saved views endpoints.

TL;DR: We’ve launched Threat Actor Profiles directly inside the Threat Events dashboard. You can now immediately pivot from a generic alert or blocked event to a profile that unmasks the "Who, Why, and How" behind a threat event.

Security teams often suffer from a visibility gap. When an attack is blocked, it's difficult to know if it was a random automated bot or a sophisticated advanced persistent threat (APT) campaign specifically targeting your industry. Finding out usually means leaving your security dashboard to hunt through external OSINT feeds or static, out-of-date threat reports. Threat Actor Profiles solve this by sharing Cloudforce One’s deep adversary research directly inside your workflow:

• Cloudflare sees the traffic in real-time across approximately 20% of the web. This means actor profiles display active malicious infrastructure the moment it touches our global edge.
• Every profile provides clear strategic and tactical modules including alternative aliases, origin tracking, historical threat event volume, and MITRE ATT&CK mapping detailing the adversary's technical methods.
• You can search the dedicated threat actor directory or click an actor's name inside any threat event to view all details and related events to the specific threat actor.

Adversary tracking is now available in the Cloudflare Dashbboard and ready to be included in your daily investigation workflow:

• Click on the Threat Actor name in the Threat Events table to open their full identity profile and review their aliases and attack stats.
• Navigate to Cloudflare Dashboard > Application Security > Threat Intelligence to explore the new Threat Actors tab. Here, you can browse a card-based directory of all established entities tracked by Cloudforce One.

Learn more in the Cloudforce One documentation ↗.

Radar now provides finer-grained traffic charts for longer time ranges. Previously, selecting a 1-3 month view on HTTP and NetFlows charts defaulted to weekly aggregation, which was too coarse to surface meaningful trends. Views longer than 3 months defaulted to monthly aggregation, returning as few as 7 data points for a 6-month range.

The new defaults are:

• 1-3 months: daily granularity (7x more data points)
• Longer than 3 months (HTTP and NetFlows): weekly granularity (4x more data points)

For example, a 12-week traffic view previously showed weekly data:

The same view now shows daily data:

Similarly, a 1-year HTTP traffic view that previously showed just 12 monthly data points now provides 52 weekly data points.

Visit Cloudflare Radar ↗ to explore the new granular views.

Cloudflare has updated Logpush datasets:

• Turnstile Events: A new dataset with fields including ASN, Action, BrowserMajor, BrowserName, ClientIP, CountryCode, EventType, Hostname, OSMajor, OSName, Sitekey, Timestamp, and UserAgent.

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

Cloudflare has updated Logpush datasets:

• DEX Device State Events (added): DeviceRegistrationProfileID.
• Gateway HTTP (added): AddedHeaders, DeletedHeaders, and SetHeaders.
• HTTP requests (added): MatchedRules.

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

The Radar post-quantum TLS support checker ↗ now also reports TLS bugs detected during the handshake test. When a scanned host exhibits compatibility issues, the results include details on the specific bugs detected, along with guidance on how to investigate and remediate each issue. The bugs section only appears for hosts where issues are found.

The following TLS bugs are detected:

• Split ClientHello — The connection fails with a fragmented post-quantum ClientHello but succeeds with classical handshakes. Typically caused by middleboxes or firewalls that cannot reassemble split TLS messages.
• HRR Failure — The server sends a HelloRetryRequest but fails to complete the handshake afterward.
• Unknown Keyshare — The server cannot handle unknown key exchange algorithms and fails instead of responding with a HelloRetryRequest as required by the TLS 1.3 specification.

Bug detection data is available through the existing /post_quantum/tls/support endpoint.

Visit the Post-Quantum Encryption ↗ page to test a host.

Security Insights scans now run more often. Cloudflare scans Free accounts every 7 days, Pro and Business accounts every 3 days, and Enterprise accounts daily.

In addition, all accounts and zones now receive scans by default. You no longer need to enable scans before Cloudflare checks your account for misconfigurations, vulnerabilities, and other security risks.

Granular on-demand scans are now available on any plan. You can trigger an on-demand scan for any zone, insight, insight type from the Cloudflare dashboard in order to quickly re-check your security posture after remediating an issue.

To learn more, refer to the Security Insights documentation.

Radar now includes two new charts on the traffic page ↗ that provide deeper insights into the composition of HTTP traffic: a content type distribution chart and an API traffic share chart.

The new Content type ↗ chart displays the distribution of HTTP response content types, grouped into high-level categories. A traffic type selector allows filtering by human, bot, or all traffic. The existing Bot vs. Human ↗ chart also gained a content type category filter, allowing users to see the bot/human split for specific content categories.

Content type categories:

• HTML — Web pages (text/html)
• Images — All image formats (image/*)
• JSON — JSON data and API responses (application/json, *+json)
• JavaScript — Scripts (application/javascript, text/javascript)
• CSS — Stylesheets (text/css)
• Plain Text — Unformatted text (text/plain)
• Fonts — Web fonts (font/*, application/font-*)
• XML — XML documents and feeds (text/xml, application/xml, application/rss+xml, application/atom+xml)
• YAML — Configuration files (text/yaml, application/yaml)
• Video — Video content and streaming (video/*, application/ogg, *mpegurl)
• Audio — Audio content (audio/*)
• Markdown — Markdown documents (text/markdown)
• Documents — PDFs, Office documents, ePub, CSV (application/pdf, application/msword, text/csv)
• Binary — Executables, archives, WebAssembly (application/octet-stream, application/zip, application/wasm)
• Serialization — Binary API formats (application/protobuf, application/grpc, application/msgpack)
• Other — All other content types

The CONTENT_TYPE dimension and contentType filter are available on the HTTP summary, timeseries groups, and timeseries endpoints.

The new API traffic ↗ chart shows the percentage of dynamic (non-cacheable) HTTP request traffic that is API-related. API traffic is identified by JSON or XML response content types (application/json, application/xml, text/xml) on HTTP requests that returned a 200 status code. A traffic type selector allows switching between human traffic, bot traffic, or all traffic.

The API_TRAFFIC dimension is available on the existing HTTP summary and timeseries groups endpoints. An apiTraffic filter (API or NON_API) can also be applied to HTTP timeseries requests to retrieve raw request counts for API-only or non-API traffic.

Visit the Radar traffic page ↗ to explore these new charts.

Radar now includes an MRT Explorer ↗ tool in the Routing section. Route collectors like RIPE RIS and RouteViews publish MRT (Multi-Threaded Routing Toolkit) dump files containing BGP announcements, withdrawals, and route attributes. The new tool parses these files entirely in the browser — nothing gets uploaded.

Paste a URL to fetch an MRT file remotely, drag and drop one onto the page, or browse for a local file. Gzip and bzip2 compressed files are supported. A sample file is also available to get started right away.

Once parsed, the tool lists every BGP event with its timestamp, prefix, AS path, OTC (Only to Customer), and community attributes.

Clicking on the "View details" action opens a modal with additional properties and the full event JSON.

When loading a file by URL, the query string captures the source so the link can be shared directly — the recipient's browser immediately fetches and parses the same file.

Try the MRT Explorer on Cloudflare Radar ↗.

Cloudflare has updated Logpush datasets:

• Email Security Post-Delivery Events: A new dataset with fields including AlertID, CompletedAt, Destination, FinalDisposition, Folder, From, FromName, MessageID, MessageTimestamp, MicrosoftTenantID, Operation, PostfixID, Reasons, Recipient, RequestedAt, RequestedBy, RequestedDisposition, Status, Subject, Success, and To.
• Magic Network Monitoring Flow Logs: A new dataset with fields including AWSVPCFlowJSON, Bits, DestinationAS, DestinationAddress, DestinationPort, DeviceID, EgressBits, EgressPackets, Ethertype, FlowProtocol, FlowTimestamp, NumFlows, PacketID, Packets, Protocol, RuleIDs, SampleRate, SampleRateType, SamplerAddress, SourceAS, SourceAddress, SourcePort, TcpFlags, and Timestamp.

• Firewall events (added): AISecurityInjectionScore, AISecurityPIICategories, AISecurityTokenCount, and AISecurityUnsafeTopicCategories.
• HTTP requests (added): AISecurityInjectionScore, AISecurityPIICategories, AISecurityTokenCount, AISecurityUnsafeTopicCategories, and Subrequests.

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

The /cdn-cgi/rum beacon endpoint now returns 405 Method Not Allowed for non-POST requests instead of 404 Not Found. The response includes an Allow: POST, OPTIONS header per RFC 9110 §15.5.6 ↗.

Previously, sending a GET or other non-POST request to this endpoint returned a 404, which was misleading because it suggested the endpoint did not exist. The new 405 response clearly indicates that the endpoint exists but only accepts POST requests.

The Web Analytics beacon (beacon.min.js) already uses POST for all metric submissions, so this change does not affect normal beacon operation. OPTIONS requests for CORS preflight continue to work as before.

For more information, refer to the Web Analytics FAQ.