Consumer Services Updates & Release Notes

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.

Your IP location on the map

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.

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:

[Traffic trends chart with weekly granularity for a 12-week view]

The same view now shows daily data:

[Traffic trends chart with daily granularity for a 12-week view]

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.

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

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.

Content type distribution

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.

API traffic share

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.

Loading a file

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.

Inspecting events

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

Event details

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

Shareable URLs

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.

Radar now provides TLD authoritative nameserver performance insights, measuring response time (latency) as observed from Cloudflare's 1.1.1.1 resolver infrastructure when forwarding queries upstream to TLD nameserver.

New widgets on TLD detail pages

• Aggregate nameserver latency : Response time percentiles (p25/p50/p75) for all authoritative nameservers of the selected TLD.
• Latency per nameserver : Median response time (p50) broken down by each authoritative nameserver over time.
• Median latency geographic distribution : p50 response time by Cloudflare data center country, displayed on a choropleth map.
• TLD ranking over time : Daily DNS magnitude rank and magnitude value with a Rank/Magnitude toggle.
• Rank change deltas : 1 week, 4 weeks, and 3 months rank changes added to the TLD magnitude table and the TLD detail info panel.

The new TLD Performance API provides the following endpoints:

• /tlds/performance/summary/{dimension} — TLD nameserver performance summarized by dimension.
• /tlds/performance/timeseries_groups/{dimension} — TLD nameserver performance over time grouped by dimension.

Available dimensions: LATENCY (aggregate p25/p50/p75), NAMESERVER_LATENCY (per-nameserver p50), LOCATION_LATENCY (per-data-center-country p50).

TLD Performance is also available as a dataset in the Data Explorer.

Check out the updated TLD detail page.

Radar is expanding its Routing section with two new widgets that give a deeper view into how networks announce address space and how RPKI ROA coverage evolves over time.

Top ASes by announced IP space on country pages

Country routing pages now include a Top ASes by announced IP space chart, breaking down the IPv4 and IPv6 address space announced from a country across the autonomous systems that originate it. The chart stacks the IPv4 and IPv6 views vertically, with the top contributing ASes called out by color and the remaining networks aggregated as Other.

RPKI ROA deployment timeseries

The RPKI sub-page adds an RPKI ROA deployment timeseries widget that tracks the share of announced BGP space covered by a valid Route Origin Authorization (ROA) over time, with separate IPv4 and IPv6 lines. A toggle switches the view between the share of covered prefixes and the share of covered IP address space. The widget is available on global, country, and AS views, so operators can monitor RPKI adoption progress and compare deployment trends across different scopes.

API endpoints

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

• /bgp/ips/top/ases - Returns the top autonomous systems by announced IP space (IPv4 /24s or IPv6 /48s), globally or filtered by country, snapped to the nearest 8-hour RIB boundary.
• /bgp/rpki/roas/timeseries - Returns RPKI ROA validation coverage over time, by share of prefixes or share of IP address space, split by IP version, with optional ASN or location filters.

Visit the Radar routing section to explore both widgets.

The Cloud Observatory on Radar now provides improved connection metric insights, offering new ways to explore TCP round-trip time, TCP handshake duration, TLS handshake duration, and response header receive duration across cloud provider origin servers.

The Cloud Observatory overview now shows connection metrics broken down by cloud provider, making it easy to compare connection performance across Amazon Web Services, Google Cloud, Microsoft Azure, and Oracle Cloud.

Each provider page now shows connection metrics for the top five regions, with a selector to rank by lowest or highest values.

Each region page now displays connection metrics as percentile distributions (25th percentile, median, and 75th percentile), providing insight into the range and variability of connection times.

These views are also available through the Origins API, using the timeseries_groups endpoint with the ORIGIN, REGION, or PERCENTILE dimension.

Radar adds three new features to the AI Insights page, expanding visibility into how AI bots, crawlers, and agents interact with the web.

Adoption of AI agent standards

The AI Insights page now includes an adoption of AI agent standards widget that tracks how websites adopt agent-facing standards. The data is filterable by domain category and updated weekly on Mondays. This data is also available through the Agent Readiness API reference.

URL Scanner reports now include an Agent readiness tab that evaluates a scanned URL against the criteria used by the Agent Readiness score tool.

For more details, refer to the Agent Readiness blog post.

Markdown for Agents savings

A new savings gauge shows the median response-size reduction when serving Markdown instead of HTML to AI bots and crawlers. This highlights the bandwidth and token savings that Markdown for Agents provides.

For more details, refer to the Markdown for Agents API reference.

Response status

The new response status widget displays the distribution of HTTP response status codes returned to AI bots and crawlers. Results are groupable by individual status code (200, 403, 404) or by category (2xx, 3xx, 4xx, 5xx).

The same widget is available on each verified bot's detail page (only available for AI bots), for example Google.

Explore all three features on the Cloudflare Radar AI Insights page.

Radar now features an expanded Routing section with dedicated sub-pages, providing a more organized and in-depth view of the global routing ecosystem. This restructuring lays the groundwork for additional routing features and widgets coming in the near future.

Dedicated sub-pages

The single Routing page has been split into three focused sub-pages:

• Overview — Routing statistics, IP address space trends, BGP announcements, and the new Top 100 ASes ranking.
• RPKI — RPKI validation status, ASPA deployment trends, and per-ASN ASPA provider details.
• Anomalies — BGP route leaks, origin hijacks, and Multi-Origin AS (MOAS) conflicts.

New widgets

The routing overview now includes a Top 100 ASes table ranking autonomous systems by customer cone size, IPv4 address space, or IPv6 address space. Users can switch between rankings using a segmented control.

The RPKI sub-page introduces a RPKI validation view for per-ASN pages, showing prefixes grouped by RPKI validation status (Valid, Invalid, Unknown) with visibility scores.

Improved IP address space chart

The IP address space chart now displays both IPv4 and IPv6 trends stacked vertically and is available on global, country, and AS views.

Check out the Radar routing section to explore the data, and stay tuned for more routing insights coming soon.

Radar ships several improvements to the URL Scanner that make scan reports more informative and easier to share:

• Live screenshots — the summary card now includes an option to capture a live screenshot of the scanned URL on demand using the Browser Rendering API.
• Save as PDF — a new button generates a print-optimized document aggregating all tab contents (Summary, Security, Network, Behavior, and Indicators) into a single file.
• Download as JSON — raw scan data is available as a JSON download for programmatic use.
• Redesigned summary layout — page information and security details are now displayed side by side with the screenshot, with a layout that adapts to narrower viewports.
• File downloads — downloads are separated into a dedicated card with expandable rows showing each file's source URL and SHA256 hash.
• Detailed IP address data — the Network tab now includes additional detail per IP address observed during the scan.

Explore these improvements on the Cloudflare Radar URL Scanner.

Cloudflare Workflows retry logic

Cloudflare Workflows allows you to configure specific retry logic for each step in your workflow execution. Now, you can access which retry attempt is currently executing for calls to

step.do():

// ctx.attempt is 1 on first try, 2 on first retry, etc.

console.log(`Attempt ${ctx.attempt}`);

You can use the step context for improved logging & observability, progressive backoff, or conditional logic in your workflow definition.

Note that the current attempt number is 1-indexed. For more information on retry behavior, refer to Sleeping and Retrying.

Sleeping and Retrying