Consumer Services Updates & Release Notes

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 is rolling out updated formatting for the data field in the 1.1.1.1 DoH JSON API (application/dns-json). During the roll out responses may use either the old or new format.

Note

These are breaking changes. The DoH JSON format has no formal RFC and its schema is not guaranteed to be stable. If you need a stable format, use the DoH wireformat instead.

Human-readable display for additional record types

Several record types previously returned their data field in RFC 3597 generic hex encoding (# ). These now use standard presentation format:

CAA: 0 issue "letsencrypt.org"
NAPTR: 100 10 "s" "SIP+D2U" "" _sip._udp.example.com.
RP: admin.example.com. txt.example.com.
IPSECKEY: 10 1 2 192.0.2.1 AwEA...
SVCB: 1 target.example.com. alpn=h2
HTTPS: 1 . alpn=h3,h2 ipv4hint=192.0.2.1
TLSA: 3 1 1 aabbccdd...
SSHFP: 1 2 aabbccdd...
OPENPGPKEY: AwEA...

Numeric DNSSEC algorithm identifiers

DNSSEC-related records now use numeric algorithm identifiers as defined in RFC 4034 instead of mnemonic names. This affects RRSIG, DS, CDS, DNSKEY, and CDNSKEY records. For example, RSASHA256 becomes 8, ECDSAP256SHA256 becomes 13, and ED25519 becomes 15. DS digest types also change from mnemonic to numeric: SHA-256 becomes 2.

Before TXT

RRSIG: A RSASHA256 2 300 ...
DS: 12345 RSASHA256 SHA-256 aabb...
DNSKEY: 257 3 RSASHA256 AwEA...

After TXT

RRSIG: A 8 2 300 ...
DS: 12345 8 2 aabb...
DNSKEY: 257 3 8 AwEA...

Other formatting changes

HINFO character-strings are now individually quoted to remove ambiguity when values contain spaces:

Before TXT

"data": "Intel Xeon Linux"

After TXT

"data": ""Intel Xeon" "Linux""

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.