Regional traffic insights: A closer look at local Internet shifts
Cloudflare Radar is expanding its view of Internet traffic with a new regional perspective. The first of two new feature sets lets you drill down from global trends to see how traffic patterns shift at a more localized level. That is useful for anyone tracking outages, policy changes, or major events that affect connectivity in a specific area rather than across the whole Internet.
The regional data is meant to complement the existing global and country-level views on Radar. Instead of only showing the big picture, it gives operators, researchers, and journalists a way to spot changes that might otherwise be hidden in aggregate numbers. The feature focuses on making comparisons easier: you can look at one region’s traffic over time and contrast it with another, or watch how a regional anomaly stands out against broader baselines.
Certificate Transparency data: From Merkle Town to Radar
The second addition brings Certificate Transparency (CT) logs into Radar’s data set. CT is a system for publicly logging the issuance of TLS certificates so that domain owners and the public can audit them. Cloudflare has been involved with CT since 2018, including running its own CT log and building Merkle Town, an earlier dashboard for exploring the CT ecosystem. That same class of data now appears on Radar, with an emphasis on making the log activity easy to explore.
With this release, you can inspect data about the certificates logged in CT on a given day, see which CAs are logging the most, and track how the log ecosystem evolves over time. The new CT insights are designed to give a clear window into one of the more operational corners of the public Internet: the infrastructure that underpins TLS trust.
Why both additions matter
Radar’s stated mission is to give deeper, more granular visibility into the health and security of the Internet. The regional traffic data addresses the health side: how is connectivity behaving in a particular place, and where are the trouble spots? The CT data addresses the security side: how trustworthy is the ecosystem that issues and verificates the certificates protecting web traffic.
These are not just new graphs bolted onto the existing dashboard. They are new ways to slice Radar’s existing traffic data and a wholly new data set that has not been a core part of the Radar interface before. Both are live starting this Birthday Week, extending the platform’s utility without changing its underlying philosophy: give users the raw material to answer their own questions about the Internet.
Regional traffic views come to Cloudflare Radar
Cloudflare Radar has long offered country-level views of Internet traffic, network performance, and routing security, with Autonomous System Number (ASN) pages adding network-level visibility in March 2022. But traffic shifts often happen below the national level—a storm knocking out power in one state, or a major event drawing attention in a specific governorate. The Radar team previously relied on internal Jupyter notebooks for such sub-national analysis. Today, that capability is publicly available through new regional traffic insights on Radar pages.
These views show traffic trends by first-order administrative divisions—the states, provinces, or departments within a country. Users can see request and byte volumes, desktop versus mobile traffic, and bot versus human breakdowns. The Data Explorer also supports joining a region with an ASN, such as viewing Comcast (AS7922) traffic in Massachusetts.
How regions are determined
Region names on Radar come from GeoNames, a crowdsourced geographical database. Cloudflare matches the IP prefix of each request to a GeoNames ID and then to the corresponding country and first-order administrative division. For example, the address 155.246.1.142 is mapped to the 155.246.0.0/16 prefix, then to GeoNames ID 5101760, identifying the United States and New Jersey.
Finding regional data
There are multiple entry points to the new regional views. Typing a region name into the search bar at the top of any Radar page returns a link to its regional traffic page. The Traffic in dropdown on any Traffic page works the same way.
Country-level pages now include a Traffic characteristics by region card with both summary and time series views. The summary view shows a map and table similar to the worldwide Traffic characteristics card. Selecting a metric updates both the table and the map, where circles at each region’s centroid are sized relative to their value. Clicking either a table row or map circle opens that region’s page.
Below the summary, a time series chart plots traffic for the top five regions by volume. These graphs can expose notable regional differences. For example, during the September 2025 Internet shutdowns in Iraq, the Traffic volume by region view shows that the Kurdistan Region and central/southern governorates followed different shutdown schedules. On days where those schedules did not align—such as September 2 and 7—traffic from Erbil and Sulaymaniyah did not drop in tandem with the declines seen in Baghdad and Basra.
What the device and bot breakdowns reveal
The regional views also surface human behavior at a local scale. Mobile devices account for just over half of HTTP request traffic on average from Nairobi County, Kenya, with a clear diurnal pattern: mobile usage falls during workday hours and climbs in the evening, while weekend mobile traffic stays elevated—consistent with Kenya’s mobile-first usage patterns and fewer people on office desktops.
Bot versus human traffic shares can be similarly informative. A graph from Lisbon shows apparent overnight increases in bot activity in early September. Because the graph shows shares, the more plausible interpretation is that human traffic declined sharply overnight: users in Lisbon drop offline around 23:00 UTC (midnight local time) and return around 05:00 UTC (06:00 local). These patterns vary by region, but signal nocturnal habits of local users.
Regional analysis in Data Explorer
Data Explorer offers additional customization through breakdown options and filters. Breaking traffic down by region at a country level produces a stacked area graph of the top 20 regions’ relative shares plus a summary bar graph. For the United States, this view shows Virginia and California together account for just over a quarter of HTTP request volume.
Drilling down to an ASN within a region is also supported in both summary and time series forms. For HTTP requests in Massachusetts by provider, Comcast (AS7922) leads with a third of the traffic, followed by Verizon Fios (AS701) at 15%, T-Mobile (AS21928) at 8.8%, Verizon Wireless (AS6167) at 5.1%, AT&T (AS7018) at 4.7%, and Charter/Spectrum (AS20115) at 4.5%. These six networks carry over 70% of the region’s request traffic.
Time-comparison views let users compare an ASN’s traffic in a region against a prior period. A week-over-week view for Comcast in Massachusetts was largely in line with the previous week, except for noticeably higher volumes on Saturday and Sunday—both rainy days that likely kept people indoors and online. Comparing the same period for Verizon Fios in Massachusetts yields a similar weekend lift, supporting that interpretation.
Cross-region comparisons are likewise possible, whether within one country or between different ones. For example, a Super Bowl matchup between the Kansas City Chiefs and Philadelphia Eagles could be examined by comparing traffic patterns in Missouri and Pennsylvania on game day against the prior week’s trends.
API access and data caveats
The underlying data is also exposed through the Radar API. The timeseries_groups and summary methods of the NetFlows and HTTP endpoints now support an ADM1 dimension, and a new geoId filter accepts GeoNames IDs. Two new endpoints, get and list, fetch geolocation details directly.
Signal quality depends on traffic volume. Country-level aggregation generally produces clean graphs, but smaller or less connected regions—particularly in developing countries—will show spikier results. Region-plus-ASN views can be noisier still. An illustrative case is Northern Darfur State in Sudan, where traffic appears intermittently and the previous-week comparison is largely incomplete, making firm conclusions difficult.
While the Internet transcends borders in principle, usage patterns remain tied to location and localized activity. The new regional views on Radar provide a sub-national lens on those trends, and the team is exploring second-order administrative divisions—counties, cities, and similar—for future expansion.
A New Lens on Certificate Transparency in Radar
Certificate Transparency (CT) has matured from a security safeguard into a critical dataset for understanding the web’s trust ecosystem. The public, append-only logs that underpin CT now record virtually every TLS certificate issued, making them a rich source for researchers, security teams, and attackers mapping external attack surfaces alike. The challenge has always been accessibility: the volume of data—multiple terabytes—makes direct analysis impractical for most.
Cloudflare’s new Certificate Transparency dashboard on Radar aims to close that gap. It is positioned as the next evolution of the company’s earlier Merkle Town project, folding CT metrics into the same interface that already surfaces traffic, security, and domain intelligence. Merkle Town will remain available until feature parity is reached, but the new page is designed to be the primary entry point for exploring CT data alongside broader Internet trends.
Charting issuance trends and certificate makeup
The dashboard opens with an overview of certificates being issued and logged over time. Because a single certificate can be submitted to multiple logs, the interface distinguishes between total log entries and unique certificates. That uniqueness calculation is bounded by the selected time range, however: a certificate appearing in different logs in separate periods will count as unique in both. All charts operate on log timestamps—when a certificate was added to a log—rather than when it was issued.
A companion view separates full certificates from pre-certificates. The latter are published before official issuance, and since CAs are not required to log a full certificate once its pre-certificate is recorded, the pre-certificate count typically dominates—reflecting the mechanics of the CT ecosystem rather than outright issuance volume.
Drilling into the characteristics of logged certificates reveals the current state of cryptographic practice. The public key algorithm chart shows RSA holding a commanding lead, with over 65% of certificates still using it, largely due to compatibility with legacy clients. ECDSA accounts for the remainder, prized for efficiency and smaller keys. The expectation is that post-quantum algorithms such as ML-DSA will eventually appear once public CAs begin offering support.
Signature algorithm data tells a similar story: RSA with SHA-256 dominates at over 65%, followed by ECDSA with SHA-384 at 19%, and ECDSA with SHA-256 at 12%. The distribution reflects a trade-off between broad interoperability and modern security strength. Validation level trends are more striking. Domain Validation (DV) certificates now account for nearly 98% of issuance, while Extended Validation (EV)—once the gold standard for trust—has been pushed toward irrelevance by the industry’s shift toward automated, low-friction issuance.
Certificate duration charts show that the industry is consolidating on short lifetimes. Fully 92% of logged certificates are valid for between 47 and 100 days, a trend driven by browser policy and the ease of automated renewal. Shorter validity windows limit the damage if a key is compromised, and the trajectory points toward even tighter limits.
The CA landscape and issuance volatility
The dashboard maps the relative weight of certificate authorities, both by corporate owner and by individual intermediate CA. The Internet Security Research Group (ISRG)—better known as Let’s Encrypt—is the clear leader, issuing more than 66% of all certificates. Google Trust Services, Sectigo, and GoDaddy follow at a distance. The CA owner chart also surfaces operational events: the Let’s Encrypt API outage of July 21-22, caused by internal DNS failures, is plainly visible as a sharp drop in issuance over that two-day period.
Filtering down to individual CAs shows Let’s Encrypt’s four main intermediates—R12, R13, E7, and E8—carrying the bulk of that load. The same data is available on dedicated pages for each CA, reachable by searching for a name or fingerprint. These pages include an information card supplied by the Common CA Database (CCADB) with details on ownership, revocation status, parent certificate, validity period, country, and root store inclusion.
CT log operators and performance
Beyond certificate issuance, the dashboard tracks the infrastructure of the CT ecosystem itself. A view of log operators over the last three months shows Sectigo managing logs with the most entries (2.8 billion), ahead of Google (2.5 billion), Cloudflare (1.6 billion), and Let’s Encrypt (1.4 billion). As with certificate counts, these rankings reflect duplicates across logs and should be read as activity levels, not as a measure of each operator’s structural importance to the system.
Individual log rankings, which can be filtered by operator, are led by Google’s xenon2025h1 and argon2025h2, Cloudflare’s nimbus2025, and Let’s Encrypt’s oak2025h2. A separate view breaks down log submissions by API type, distinguishing the original RFC 6962 protocol from the newer, more efficient static CT API.
Log-specific pages provide a deeper look at any given log. Beyond the same charts and filters, each includes an information card from Google Chrome’s log list, plus performance radars tracking uptime and response time over 90 days as observed by Cloudflare’s CT monitor. Those metrics offer a practical gauge for whether a log is meeting the ongoing requirements for inclusion in programs like Google’s.
Coverage by domain, wildcard, and IP
Certificate subject coverage rounds out the dashboard. The top-level domain distribution shows .com leading by a wide margin with 45% of pre-certificates, followed by TLDs such as .dev and .net. Two half-donut charts add context on scope: nearly a quarter of certificates use wildcards to cover multiple subdomains, while the overwhelming majority of certificates exclude IP addresses from their Subject Alternative Name fields—a post-2017 baseline requirement that limits some private key use cases.
Domain-level detail is extended on Radar’s domain pages themselves. The certificates table there now supports expandable rows that expose, for each certificate, its SHA-256 fingerprint, subject and issuer components (CN, O, and C), the NotBefore and NotAfter validity window, and the CT log where it was recorded.
All of this data is accessible programmatically through Radar’s CT API and its Data Explorer, with chart downloads available for embedding reports and live dashboards.
