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.

AS-level connectivity

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.

Upstream providers

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.

API endpoints

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 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.

What's available

• 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:

New 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.

Updated fields in existing datasets

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.

Your IP location on the map

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.

Extended AS information

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.

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.

Why this matters

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

How it works

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.

Why this matters

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.

How to use it

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:

Weve 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.

Why this matters

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 Ones 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.

How to use it

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 9.

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 .

Why this matters

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.

How to use it

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.