--- title: Cloudflare Radar description: Cloudflare Radar is a hub that showcases global Internet traffic, attacks, and technology trends and insights. It is powered by data from Cloudflare’s global network, as well as aggregated and anonymized data from Cloudflare’s 1.1.1.1 public DNS resolver. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/index.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # Cloudflare Radar Get access to Cloudflare's data on global Internet traffic. Available on all plans [Cloudflare Radar ↗](https://radar.cloudflare.com) is a hub that showcases global Internet traffic, attacks, and technology trends and insights. It is powered by data from [Cloudflare’s global network ↗](https://www.cloudflare.com/network/), as well as aggregated and [anonymized data](https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver/) from Cloudflare’s [1.1.1.1 public DNS resolver](https://developers.cloudflare.com/1.1.1.1/). Using [Radar's API](https://developers.cloudflare.com/api/resources/radar/) you can access Cloudflare's data on global Internet traffic. Radar's API is free, allowing academics, technology professionals, and other web enthusiasts to investigate Internet usage across the globe. Data available via Radar API endpoints is made available under the [CC BY-NC 4.0 ↗](https://creativecommons.org/licenses/by-nc/4.0/) license. [ Get started ](https://developers.cloudflare.com/radar/get-started/) [ Radar website ](https://radar.cloudflare.com/) --- ## Features ### Make your first API request Start learning how to use Radar's API by making your first request. [ Make your first API request ](https://developers.cloudflare.com/radar/get-started/first-request/) ### Compare data What to know before making comparisons between locations, [autonomous systems ↗](https://www.cloudflare.com/en-gb/learning/network-layer/what-is-an-autonomous-system/), and more. [ Compare data ](https://developers.cloudflare.com/radar/get-started/making-comparisons/) ### URL Scanner Understand the security, performance, technology, and network details of a URL with a publicly shareable report. [ Use URL Scanner ](https://developers.cloudflare.com/radar/investigate/url-scanner/) --- ## More resources [Investigate](https://developers.cloudflare.com/radar/investigate/) Explore the diverse data available in Cloudflare Radar, including NetFlows, HTTP requests, DNS queries, and much more. [@CloudflareRadar](https://x.com/cloudflareradar) Follow @CloudflareRadar on X to learn about Internet trends, as seen by the Cloudflare global network. [@cloudflareradar](https://noc.social/@cloudflareradar) Follow @cloudflareradar on Mastodon to learn about Internet trends, as seen by the Cloudflare global network. [@radar.cloudflare.com](https://bsky.app/profile/radar.cloudflare.com) Follow @radar.cloudflare.com on Bluesky to learn about Internet trends, as seen by the Cloudflare global network. [Cloudflare blog](https://blog.cloudflare.com/tag/cloudflare-radar/) Read articles about the latest trends and updates on Cloudflare Radar. [MCP Server](https://github.com/cloudflare/mcp-server-cloudflare/tree/main/apps/radar#cloudflare-radar-mcp-server-) Enable any MCP client to access and explore trends and insights on Cloudflare Radar. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}}]} ``` --- --- title: Glossary description: This page provides a list of terms and concepts to help you understand Radar and the information shown. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/glossary.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # Glossary This page provides a list of terms and concepts to help you understand Radar and the information shown. ## AI bot and crawler traffic HTTP request activity from user agents associated with AI assistants, AI data scrapers, and AI search crawlers. This information is normalized to show trends in traffic volume, providing insights into the activity levels of AI-driven web interactions over time. User agents included in this analysis are derived from the AI-focused user agents listed in the [ai.robots.txt ↗](https://github.com/ai-robots-txt/ai.robots.txt) repository. ## Application-level attacks Layer 7 attack information based on mitigated requests, including the most frequent mitigation techniques as well as the trend of mitigated request volume over time. For the "Application layer attack volume" and "Mitigated traffic sources" graphs, the selected location or ASN is the source of the mitigated requests. For the "Application layer attack distribution" graph, the Origin Location graph shows where attacks targeting the selected location are coming from and the Target Location graph shows the target locations of attacks coming from the selected location. "Application layer attack distribution" insights are not available at an ASN level. ## Authentication methods [SPF ↗](https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/#spf), [DKIM ↗](https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/#dkim), and [DMARC ↗](https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/#dmarc) are policy-driven email authentication methods and when used together, they help prevent spammers, phishers, and other unauthorized parties from sending emails on behalf of a domain they do not own. PASS is the share of processed messages that pass the associated checks. FAIL is the share of processed messages that fail the associated checks. NONE is the share of processed messages for which no associated policy could be found. Data for these metrics comes from Cloudflare’s email routing service. ## Autonomous systems The Internet is a network of networks, and autonomous systems are the networks that make up the Internet. More specifically, an autonomous system (AS) is a large network or group of networks that has a unified routing policy - the process by which a path through one or more networks is chosen. Data packets hop from one AS to another until they reach their final destination. Every computer or device that connects to the Internet is connected to an AS. ISPs have one or more ASes, and each AS is assigned an official Autonomous System Number (ASN) for use in Border Gateway Protocol (BGP) routing. For example, Cloudflare's ASN is AS13335\. Learn more in the [Cloudflare Learning Center ↗](https://www.cloudflare.com/learning/network-layer/what-is-an-autonomous-system/). ## Autonomous System Provider Authorization (ASPA) [Autonomous System Provider Authorization (ASPA) ↗](https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/) is a cryptographic object within the [Resource Public Key Infrastructure (RPKI) ↗](https://en.wikipedia.org/wiki/Resource%5FPublic%5FKey%5FInfrastructure) that extends route security beyond origin validation. While RPKI Route Origin Authorizations (ROAs) verify which [Autonomous System (AS) ↗](https://www.cloudflare.com/learning/network-layer/what-is-an-autonomous-system/) is authorized to originate a prefix, ASPA validates the BGP `AS_PATH` by allowing an AS to declare its authorized upstream transit providers, enabling detection of route leaks and certain BGP hijacks with forged path segments. Each ASPA record is created by a **Customer AS (CAS)** and lists a **Set of Provider ASes (SPAS)** authorized to propagate its routes upstream. Routers use these Customer-to-Provider relationships to evaluate whether a BGP `AS_PATH` is consistent with the legitimate routing topology, producing a verification outcome of `Valid`, `Invalid`, or `Unknown`. Although the IETF specification remains in draft, support for creating ASPA objects is available in RIR portals such as [ARIN ↗](https://www.arin.net/announcements/20260120/) and [RIPE NCC ↗](https://labs.ripe.net/author/tim%5Fbruijnzeels/aspa-in-the-rpki-dashboard-a-new-layer-of-routing-security/), and validation logic has been implemented in routing stacks including [OpenBGPD ↗](https://www.undeadly.org/cgi?action=article;sid=20231002135058) and [BIRD ↗](https://bird.network.cz/?get%5Fdoc&v=20&f=bird-5.html). ## BGP announcements Border Gateway Protocol (BGP) is the routing protocol for the Internet. Much like the post office processing mail, BGP picks the most efficient routes for delivering Internet traffic. A BGP announcement is a way for an AS to say to another, "When you receive traffic to this network prefix, please send it to me". That message is then processed and (possibly) forwarded to other ASes, allowing for every AS in the path to learn where to send traffic to that network prefix. Learn more in the [Cloudflare Learning Center ↗](https://www.cloudflare.com/learning/security/glossary/what-is-bgp/). On Cloudflare Radar, we provide time series charts for both the volume of BGP messages announced by ASes and the total size of their announced IP address space. BGP message volume shows the level of overall routing activity for a given AS, while announced IP address space indicates the size of the networks a given AS operates over time. We represent the IP address space size with the number of minimum routable network prefix sizes, which are the number of /24 prefixes for IPv4 and /48s for IPv6\. Correspondingly, a /24 prefix represents 256 IP addresses while a /48 represents 2^80 IP addresses. ## BGP route leaks [BGP route leaks ↗](https://www.rfc-editor.org/rfc/rfc7908.html) are defined as the propagation of routing announcements beyond their intended scope. In Cloudflare Radar, you can inspect the detected route leak events on the corresponding autonomous system number (ASN) pages. The columns in the table are defined as follows: * `From`: The autonomous system (AS) from which the routes are learned from. * `By`: The AS that leaked the routes, or the leaker. * `To`: The AS that received and propagated the leaked routes. * `Start` and `End`: The starting and ending time of a route leak event. * `BGP Msgs.`: The number of BGP announcements that contain leaked routes. * `Prefixes`: The number of IP prefixes a route leak event affects. * `Origins`: The number of origin ASes a route leak event affects. * `Vantage Points`: The number of route collectors that observed a route leak event. Learn more about our route leak detection system design and usages in [How we detect route leaks and our new Cloudflare Radar route leak service ↗](https://blog.cloudflare.com/route-leak-detection-with-cloudflare-radar/) blog post. ## BGP origin hijacks [BGP origin hijack ↗](https://www.cloudflare.com/learning/security/glossary/bgp-hijacking/) is one type of BGP anomaly where networks falsely announce ownership for groups of IP addresses (prefixes) that they do not own, control, or route to. A BGP origin hijack can redirect Internet traffic to the hijacker from its legitimate destination, causing data loss with potential leak of private/confidential information. In Cloudflare Radar, you can inspect the detected BGP origin hijack events in the "BGP Origin Hijacks" table. The columns of the table are defined as follows: * `ID`: Event ID, clickable and navigates to the event details page. * `Detected Origin`: The AS that originated the prefixes at the time of detection, potentially being a BGP hijacker. * `Expected Origin(s)`: The AS(es) that are expected to originate the corresponding prefixes based on various evidences. * `Start Time (UTC)` and `Duration`: The detected timestamp in UTC with a human-readable time duration for how long the event lasted. Ongoing events will not have a duration value, indicated by the `--` sign. * `BGP Messages`: The number of BGP messages that contain the detected anomaly. * `Prefixes`: The prefixes hijacked during the event, showing only one full prefix due to table space limitation. * `Confidence`: The level of confidence that we have on the event being a true hijacks. Values can be `High`, `Medium`, or `Low`. * `Tags`: The relevant evidence presented as short tags, presenting key facts we compiled using additional data sources, such as RPKI validation results or network relationship. You can also access the detection result programmatically via our [public API](https://developers.cloudflare.com/api/resources/radar/subresources/bgp/subresources/hijacks/subresources/events/methods/list/) ([CC BY-NC 4.0 ↗](https://creativecommons.org/licenses/by-nc/4.0/) license). ## BGP real-time routes Cloudflare Radar's prefix routing page displays real-time BGP routes as a [Sankey diagram ↗](https://en.wikipedia.org/wiki/Sankey%5Fdiagram). This visualization is built using MRT data from [RouteViews ↗](https://www.routeviews.org/routeviews/) and [RIPE RIS ↗](https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/), combined with real-time streams from RouteViews' Kafka instance and [RIS Live ↗](https://ris-live.ripe.net/). By default, the route visualization shows paths from the originating AS to [Tier-1 networks ↗](https://en.wikipedia.org/wiki/Tier%5F1%5Fnetwork), omitting the segments from Tier-1 networks to BGP route collectors for clarity. Users can choose to see the complete paths using the "Show full paths" toggle. Above the visualization, a table details the prefix origin, including the originating AS, its visibility percentage across route collectors, and [RPKI ↗](https://blog.cloudflare.com/rpki-details/) validation status (`valid`, `invalid`, `unknown`). Hovering over a link in the diagram reveals a tooltip with the connected ASNs, the observing BGP route collectors (from [RIPE RIS ↗](https://ris.ripe.net/docs/route-collectors/) and [RouteViews ↗](https://www.routeviews.org/routeviews/collectors/)), and the last update timestamp. ## Certificates Encryption is a critical part of a safe Internet. SSL/TLS is the standard security technology for establishing an encrypted link between a client and a server. In Cloudflare Radar, you can view all certificates issued for a given domain by a trusted Certificate Authority that are listed in active certificate transparency logs. You can review the certificates issued for your domain name to ensure that there have been no incorrect or fraudulent issuances of certificates associated with your domains. You can also sign up to receive alerts from our certificate transparency monitor in the [Cloudflare Dashboard ↗](https://dash.cloudflare.com/). ## Certificate Transparency [Certificate Transparency (CT) ↗](https://certificate.transparency.dev/) is an Internet security standard for monitoring and auditing the issuance of digital certificates issued by Certification Authorities (CAs). CT helps detect misissued or malicious certificates by requiring CAs to publicly log all certificates they issue in append-only, verifiable logs. These logs are monitored by various entities, including browsers and security researchers, to ensure transparency and trust in the certificate ecosystem. Key entities in CT include: * **CAs:** Organizations that issue certificates. * **CT Logs:** Public, append-only logs where issued certificates are recorded. * **Monitors:** Parties that check logs for correctness. The data available in Cloudflare Radar is derived from the CT logs currently monitored by Cloudflare. This enables visibility into certificate issuance trends, distributions, and metadata across the web. ## Connection characteristics Share of inbound connections to Cloudflare from mail transfer agents with the given characteristics. “IP Version” breaks down connections made over IPv4 and IPv6\. “Encryption” breaks down connections made over an encrypted connection using TLS, and those made over an unencrypted connection, in the clear. Data for these metrics comes from Cloudflare’s email routing service. ## Connection quality Connection quality metrics include download and upload speed, latency (round-trip time), and latency jitter (round-trip time stability), reflecting the best expected performance for specific countries or ASNs. These metrics are derived from speed tests initiated by end users on the [Cloudflare Speed Test website ↗](https://speed.cloudflare.com/), aggregated over the previous 90 days. The underlying raw data is freely accessible for analysis through [Measurement Lab's BigQuery ↗](https://blog.cloudflare.com/aim-database-for-internet-quality/). In speed, latency, and jitter rankings, only countries where users run speed tests with sufficient regularity are included. Consequently, certain countries may be excluded from the rankings, even though their data can be found in other sections of Radar. Cloudflare Speed Test measures latency multiple times over the course of the test. Measurements taken before a download or upload begins are aggregated into idle latency and jitter, while measurements taken while a download or upload is in progress are aggregated as loaded latency and jitter. ## Content categories Cloudflare uses a variety of data sources to categorize domains. Using Cloudflare Radar, you can view the content categories associated with a given domain. Cloudflare customers using [Cloudflare Gateway](https://developers.cloudflare.com/cloudflare-one/traffic-policies/domain-categories/) or [1.1.1.1 for Families](https://developers.cloudflare.com/1.1.1.1/setup/#1111-for-families) can decide to block certain categories, like "Adult Content", in addition to security threats like malware and phishing. In some cases, a domain may be miscategorized. For example, a social media site might be categorized as "Shopping & Auctions". If you believe a domain is miscategorized, or a domain has not yet been categorized, please provide your suggested category using [this form ↗](https://radar.cloudflare.com/domains/feedback) to bring it to our attention. ## DNS The [Domain Name System (DNS) ↗](https://www.cloudflare.com/learning/dns/what-is-dns/) is a network service that is most commonly used to translate human-readable domain names into numerical IP addresses that computers can use to talk to each other. It is an essential Internet service, and is also used to look up other network-related information. The data displayed on Radar for DNS is based on aggregated and anonymized DNS lookups to Cloudflare's [1.1.1.1](https://developers.cloudflare.com/1.1.1.1/) public resolver service. ## DNS magnitude DNS Magnitude is a metric originally developed by [nic.at ↗](https://www.nic.at/media/files/pdf/dns-magnitude-paper-20200601.pdf) (PDF) to estimate a domain’s overall visibility on the Internet. Instead of only counting the total number of DNS queries, DNS Magnitude incorporates a sense of how many unique clients send queries to domains within the TLD. This approach gives a more accurate picture of a TLD’s reach, since a small number of sources can generate a large number of queries. Our ranking is based on queries observed at Cloudflare’s [1.1.1.1](https://developers.cloudflare.com/1.1.1.1/) public resolver. We aggregate individual client IP addresses into subnets, referred to here as "networks". The magnitude value ranges from 0 to 10, with higher values (closer to 10) indicating that the TLD is queried by a broader range of networks. This reflects greater global visibility and, in some cases, a higher likelihood of name collision across different systems. [According to ICANN ↗](https://www.icann.org/resources/pages/name-collision-2013-12-06-en), a name collision occurs when an attempt to resolve a name used in a private name space (such as under a non-delegated Top-Level Domain) results in a query to the public DNS. When the administrative boundaries of private and public namespaces overlap, name resolution may yield unintended or harmful results. For example, if ICANN were to delegate `.home`, that could cause significant issues for hobbyists that use the (currently non-delegated) TLD within their local networks. ## Domain rankings Domain Rankings is based on our anonymized and aggregated [1.1.1.1 DNS resolver](https://developers.cloudflare.com/1.1.1.1/) data, complies with our [privacy policy ↗](https://www.cloudflare.com/en-gb/privacypolicy/), and aims to identify the top most popular domains that reflect how people use the Internet globally. Domain Rankings’ popularity metric is best described as the estimated number of unique users that access a domain over some period of time. Trending domains are domains which are currently experiencing an increase in popularity. Domains Trending Today are domains spiking in popularity, reflecting increased interest potentially related to a particular event or a topic. Domains Trending This Week are domains that have steadily grown in popularity, reflecting an increase of their user base over the week. ## Geographical distribution Countries contributing traffic to this AS, and their relative contribution as percentage of the total AS traffic seen by Cloudflare. ## HTTP origins HTTP origins trends provide visibility into the status of traffic between [Cloudflare's global network ↗](https://www.cloudflare.com/network/) and cloud-based [origin infrastructure ↗](https://www.cloudflare.com/learning/cdn/glossary/origin-server/). This data comes from requests sent by Cloudflare to origin servers. The metrics track key indicators such as HTTP status codes, response times, and traffic volume over time, allowing us to identify degradations, outages, or anomalies in origin server performance and availability. ## Internet outages Internet connectivity can experience outages or disruptions due to a number of factors. These factors include power outages, damage to fiber optic cables, severe weather, natural disasters, or government directed shutdowns. Outages may be sub-national or national in geographic scope, or may impact one or more [ASNs ↗](https://www.cloudflare.com/en-gb/learning/network-layer/what-is-an-autonomous-system/). Some outages may be brief, lasting just a few minutes, while others can stretch on for months — the duration can be related, in part, to the underlying cause. Internet outages listed in the Cloudflare Radar Outage Center are notable drops in traffic that have generally been corroborated with third party-information, which may include a social media or status page post from a telecommunications provider, a news report, or industry/community mailing lists. An early warning signal that an Internet outage may be underway on a given network or in a given country is an anomalous drop in traffic as compared to historical traffic patterns and trends. Internet anomalies listed in the Cloudflare Radar Outage Center represent an algorithmically-observed anomalous drop in traffic for the listed entity. If a given entry is marked as verified, it means that we have manually corroborated the observed drop in traffic across multiple Cloudflare data sources and/or third-party sources such as [IODA ↗](https://ioda.inetintel.cc.gatech.edu/), or third-party sources of information, such as those listed above. In the case of the latter, an associated Internet outage event will be opened, with the event listed in the Internet Outages table (and API). ## Internet services ranking Internet services ranking is based on our anonymized and aggregated [1.1.1.1 DNS resolver](https://developers.cloudflare.com/1.1.1.1/) data, complies with our [privacy policy ↗](https://www.cloudflare.com/en-gb/privacypolicy/), and aims to identify the top most popular Internet services that reflect how people use the Internet globally. A service represents one or more domains aggregated together. Ranking popularity metric is best described as the estimated number of unique users that access domains associated with a service, over some period of time. ## Internet traffic trends Trends observed in Internet traffic originating globally or within a given location or autonomous system within the selected time range, based on aggregated data from our network. ## IP address geolocation IP address geolocation is the term used for the process of associating an IP address with a location in the physical world. IP geolocation used on Cloudflare Radar comes from a third-party database. Note that a number of factors may affect the accuracy of the geolocation information, including mobile network architecture, the use of VPN services, and the use of privacy-protecting proxy services. Learn more from Cloudflare's documentation on [IP geolocation](https://developers.cloudflare.com/network/ip-geolocation/#report-an-incorrect-ip-location) about how to suggest a correction if you believe the location provided is incorrect. ## IPv6 adoption The IPv4 vs. IPv6 graph shows the distribution of traffic by IP version, and is intended to highlight IPv6 adoption trends. Note that prior to January 23, 2023, the IPv6 percentage shown in the chart was calculated as (IPv6 requests / IPv4+IPv6 requests). After that date, the IPv6 percentage is calculated as (IPv6 requests / requests for dual-stacked content). ## IQI The Internet Quality Index estimates connection performance under average utilization, such as web browsing. It is based on end user measurements against a fixed set of Cloudflare and third-party targets, providing numbers for bandwidth, round-trip time (latency), and DNS response time, aggregated by continent, country, or ASN. The IQI methodology requires a minimum number of measurements to generate estimates. As a result, graphs for smaller countries and ASNs may display occasional gaps, especially during nighttime. These gaps do not indicate outages. The number of measurements underlying IQI does not necessarily correlate with the volume of traffic observed by Cloudflare in a specific country or ASN. ## IRR AS-SETs An IRR AS-SET is a named collection of Autonomous System Numbers (ASNs) within the Internet Routing Registry (IRR) used to define and manage BGP routing policies. By grouping related networks, such as customers and downstream peers, under a single identifier, network operators can automate the creation of BGP filters, which are essential for preventing the propagation of BGP route leaks. AS-SETs can be hierarchical, meaning they can include other AS-SETs as members, creating a scalable but complex structure. To quantify this complexity, the "AS Cone" measures the total number of unique ASNs in a fully expanded set (its downstream footprint), while "Upstreams" measures how many other AS-SETs include it directly or indirectly, providing insight into its role in the global routing system. An AS-SET does not inherently includes its owner networks. Cloudflare Radar infers the owner by matching the AS-SET name on [PeeringDB ↗](https://www.peeringdb.com/) or by the name itself. When an AS-SET's owner can be inferred via both methods, we prefer the PeeringDB information. ## Leaked credentials [Leaked credentials detection](https://developers.cloudflare.com/waf/detections/leaked-credentials/) scans incoming HTTP requests for known authentication patterns from common web apps and any custom detection locations that were configured. Cloudflare Radar provides visibility into aggregate trends in authentication requests, including the detection of leaked credentials. ## Mobile operating systems The Mobile Operating Systems graph shows the distribution of mobile device requests by operating system, representing trends observed in Internet traffic originating globally or within a given location or autonomous system within the selected time range, based on aggregated data from our network. "Mobile device" includes phones and tablets only, and does not include other types of devices, such as those classified as desktops/laptops, smart TVs, or gaming consoles. ## Most observed TLDs [Top-level domains, also known as TLDs ↗](https://www.cloudflare.com/learning/dns/top-level-domain/), are found in the right-most portion of a hostname. As of February 2024, there are nearly 1600 Top Level Domains listed in the [IANA Root Zone Database ↗](https://www.iana.org/domains/root/db). On Radar, we are sharing our own perspective on these TLDs, highlighting those with the largest shares of spam and malicious emails. The analysis is based on the sending domain’s TLD, found in the `From:` header of an email message. Data for this metric comes from Cloudflare’s cloud email security service. ## Network-level DDoS attacks Attacks mitigated by our Level 3 and 4 Denial of Service Attack prevention systems. We show the most used attack vectors as well as the change in attack volume over the selected time range. Selected location is the location of the data center(s) where the attacks were mitigated. Target industry and vertical categories are associated with the customers being attacked. Industry categories include business types grouped by their primary activities, such as information technology and services, retail, or telecommunications. Vertical categories are high-level groupings that incorporate related industries, such as the "Internet and Telecom" vertical, which includes industries such as "Internet" and "Telecommunications". Network-level DDoS attacks graphs are based on traffic measured in bytes. ## Post-quantum encryption adoption The Post-Quantum Encryption Adoption graph shows the share of HTTPS requests to Cloudflare that are encrypted with post-quantum (PQ) cryptography. Additional details about Cloudflare's support for PQ cryptography can be found at [Cloudflare Research ↗](https://pq.cloudflareresearch.com/). ## Post-quantum origin support The post-quantum origin support dataset provides insights into the TLS key exchange algorithms supported by scanned customer origin servers. Additional details about post-quantum cryptography between Cloudflare and origin servers can be found in the [PQC to your origin](https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-to-origin/) documentation. ## Robots.txt A [robots.txt ↗](https://www.cloudflare.com/learning/bots/what-is-robots-txt/) file contains instructions for bots that tell them which webpages they can and cannot access. The data displayed for robots.txt is based on successfully parsed robots.txt files from the top 10,000 domains. From these files, we count the occurrences of each user agent under the `Allow` and `Disallow` directives. A user agent is classified as "fully allowed" or "fully disallowed" if the directive value is `*`. Otherwise, if the user agent is only allowed or disallowed to crawl specific paths, it is classified as "partially allowed" or "partially disallowed." Currently, we only include AI-focused user agents listed in the [ai.robots.txt ↗](https://github.com/ai-robots-txt/ai.robots.txt) repository. ## TCP resets and timeouts In the Transmission Control Protocol (TCP), client-initiated connection resets (via the RST flag, TCP's "panic button") are atypical, and indicate to the server that _something went wrong_ requiring the connection to be closed immediately. Similarly, connection timeouts (where the server closes a connection due to an unresponsive client) should not happen in conventional data exchanges. For comparison, a typical TCP connection consists of a 3-way handshake initiated by a client with a SYN packet to the server, then a data exchange moderated with ACK and PSH flags in the data packets, and finally a graceful close initiated from either side with a FIN packet. A FIN close is considered graceful because it ensures both sides complete their data transfer before closing the connection. In contrast, a timeout or RST flag triggers a hard stop, even if data is waiting to be sent or acknowledged. See [RFC 9293 ↗](https://datatracker.ietf.org/doc/html/rfc9293) for more details on the TCP protocol. A TCP server may see timed-out or reset connections for a variety of reasons. Some are benign, such as client applications that lose connectivity or abruptly shut down (e.g., browsers cleaning up closed tabs or port scanners). Others are more concerning, such as [DoS attacks ↗](https://www.cloudflare.com/learning/ddos/syn-flood-ddos-attack/) or third-party interference. In some cases, a close examination of the packets in a connection can help to shed light on the reason for termination. For example, [Global, Passive Detection of Connection Tampering ↗](https://research.cloudflare.com/publications/SundaraRaman2023/) finds that certain packet patterns can be linked to middlebox connection tampering. On Cloudflare Radar’s [Security & Attacks page ↗](https://radar.cloudflare.com/security-and-attacks), you can view statistics on resets and timeouts from a sample of TCP connections to Cloudflare’s servers, broken down by how far the connection progressed before termination. The plot lines are defined as follows: * **Post-SYN (mid-handshake)**: Connection resets or timeouts after the server received only a single SYN packet. * **Post-ACK (immediately post-handshake)**: Connection resets or timeouts after the server received both a SYN packet and an ACK packet, meaning the connection was successfully established. * **Post-PSH (after first data packet)**: Connection resets or timeouts after the server received a packet with PSH flag set, following connection establishment. The PSH flag indicates that the TCP packet contains data (such as a TLS Client Hello message) ready to deliver to the application. * **Later (after multiple data packets)**: Connection resets within the first 10 packets from the client, but after the server has received multiple data packets. * **None**: All other connections. Learn more about the TCP resets and timeouts dataset in our [blog post ↗](https://blog.cloudflare.com/tcp-resets-timeouts). ## Threat categories Attackers use multiple types of techniques when carrying out email-based attacks, including links or attachments leading to malware; identity deception, where the message appears to be coming from a trusted contact; and brand impersonation, where the message appears to be coming from a trusted brand. Categories are assigned to the various types of threats found during the analysis of a malicious email message, and a single message can have multiple categories. These categories are aggregated into “Link”, “Attachment”, “Impersonation”, and “Other” groupings. “Link” groups individual threat types where the attacker is trying to get the user to click on something, “Attachment” groups individual threat types where the attacker has attached a file to the email message, and “Impersonation” groups individual threat types where the attacker is impersonating a trusted brand or contact. The “Other” grouping includes other threat types not covered by the previous three. The percentages represent the share of malicious email messages where the given threat categories have been found. Data for this metric comes from Cloudflare’s cloud email security service. ## Threat classification Malicious email messages may be part of a phishing campaign, where recipients are tricked into sharing personal information like login details, or they are an attempt to spread malware through embedded images, links, or attachments. The percentage shown represents the share of processed messages that are classified as malicious. Data for this metric comes from Cloudflare’s cloud email security service. ## Traffic type filter * **Human Only Traffic**: Traffic that our algorithms determine as being generated by human activity. * **Automated Only Traffic**: Traffic that our algorithms determine as being generated by bot or automated script activity. * **All Traffic**: Use all traffic, which includes both human activity and automated activity. ## Trends Based on the aggregated HTTP/s metadata we see, we are able to show trends about a diverse set of metrics, including the distribution of mobile device vs. desktop traffic, the percentage of traffic detected as coming from bots, and the distribution of user agents/browsers. We also provide insights into the usage of HTTPS and IPv6. ## Verified bots Bot traffic describes any non-human traffic to a website or an app. Some bots are useful, such as search engine bots that index content for search or customer service bots that help users. Other bots may be used to perform malicious activities, such as break into user accounts or scan the web for contact information to send spam. Verified bots, such as the ones from search engines, are usually transparent about who they are. Cloudflare manually approves well-behaved services that benefit the broader Internet and honor robots.txt. Each entry on the Verified Bots list exists because a corresponding IP address was seen associated with a verified bot in the last 30 days. A verified bot is not necessarily good or bad. ## Visitor location The data displayed on domain-specific geographic traffic patterns is based solely on data from our recursive DNS services. All data displayed is in accordance with our privacy policies and commitments. This data may include attack traffic and cross-origin requests. ## Web crawlers [Web crawlers ↗](https://www.cloudflare.com/learning/bots/what-is-a-web-crawler/) are a type of bot that browses the Internet to collect and index website content. They are used by search engines like Google or Bing to make pages discoverable in search results. They are also used by AI platforms, either to gather content for training large language models, or to retrieve up-to-date information for AI assistants. In both search and AI cases, crawlers work by following links from one page to another, creating a map of online content. Radar's crawl-to-refer ratio metric is calculated by first mapping crawl requests for HTML pages based on the `User-Agent` header, and referral requests for HTML pages based on the `Referer` header, by platform (e.g., the ratio for Google is based on crawl requests from Googlebot, and referral requests from Google platforms). As with other traffic metrics on Radar, the aggregation resolution for the ratio data is based on the length of the selected timeframe. Additionally, note that traffic referred by native apps may not include a `Referer` header. As such, because the referral counts only include traffic from Web-based tools, these calculations may overstate the respective ratios, but it is unclear by how much. ## WHOIS WHOIS is a standard for publishing the contact and nameserver information for all registered domains. Each registrar maintains their own WHOIS service. Anyone can query the registrar's WHOIS service to reveal the data behind a given domain. ## Workers AI [Workers AI](https://developers.cloudflare.com/workers-ai/) allows you to run machine learning models, on the Cloudflare network, from your own code -- whether that be from Workers, Pages, or anywhere via the Cloudflare API. The data displayed for Workers AI is based on the number of Cloudflare accounts using a model during a specific time interval. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/glossary/","name":"Glossary"}}]} ``` --- --- title: API reference image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/api-reference.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # API reference ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/api-reference/","name":"API reference"}}]} ``` --- --- title: MCP server image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/mcp-server.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # MCP server ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/mcp-server/","name":"MCP server"}}]} ``` --- --- title: Release notes description: Review recent changes to Cloudflare Radar. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/release-notes.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # Release notes [ Subscribe to RSS ](https://developers.cloudflare.com/radar/release-notes/index.xml) ## 2026-04-01 **Promote Routing to a dedicated section with sub-pages** * Expanded the Routing page into a full section with dedicated [Overview](https://radar.cloudflare.com/routing), [RPKI](https://radar.cloudflare.com/routing/rpki), and [Anomalies](https://radar.cloudflare.com/routing/anomalies) sub-pages. * Added new **Top 100 ASes** widget to the routing overview, with rankings by customer cone, IPv4 address space, and IPv6 address space. * Added new **RPKI prefix validation** widget showing per-ASN prefixes grouped by validation status (Valid, Invalid, Unknown). * Improved the IP address space chart to display both IPv4 and IPv6 trends on all views including global. ## 2026-03-06 **Add region filtering and AS/location dimensions to API** * Added region filtering across all location-aware pages, including continents, geographic subregions, political regions (EU, ASEAN, African Union), and US Census regions/divisions. * Added traffic volume insights by top autonomous systems and countries/territories. * Added AS and location dimensions to the [HTTP](https://developers.cloudflare.com/api/resources/radar/subresources/http/), [DNS](https://developers.cloudflare.com/api/resources/radar/subresources/dns/), and [NetFlows](https://developers.cloudflare.com/api/resources/radar/subresources/netflows/) APIs. * Added breadcrumb navigation. ## 2026-02-27 **Add Post-Quantum and Key Transparency insights** * Added new [Post-Quantum](https://developers.cloudflare.com/api/resources/radar/subresources/post%5Fquantum/) API: * [/post\_quantum/tls/support](https://developers.cloudflare.com/api/resources/radar/subresources/post%5Fquantum/subresources/tls/methods/support/) \- Tests whether a host supports post-quantum TLS key exchange. * [/post\_quantum/origin/summary/{dimension}](https://developers.cloudflare.com/api/resources/radar/subresources/post%5Fquantum/methods/summary/) \- Returns origin post-quantum data summarized by key agreement algorithm. * [/post\_quantum/origin/timeseries\_groups/{dimension}](https://developers.cloudflare.com/api/resources/radar/subresources/post%5Fquantum/methods/timeseries%5Fgroups/) \- Returns origin post-quantum timeseries data grouped by key agreement algorithm. * Launched [Post-Quantum Encryption](https://radar.cloudflare.com/post-quantum) page. * Launched [Key Transparency](https://radar.cloudflare.com/key-transparency) page. ## 2026-02-25 **Add RPKI ASPA deployment insights** * Added new [ASPA](https://developers.cloudflare.com/api/resources/radar/subresources/bgp/subresources/rpki/subresources/aspa/) API endpoints: * [/bgp/rpki/aspa/snapshot](https://developers.cloudflare.com/api/resources/radar/subresources/bgp/subresources/rpki/subresources/aspa/methods/snapshot/) \- Retrieves current or historical ASPA objects. * [/bgp/rpki/aspa/changes](https://developers.cloudflare.com/api/resources/radar/subresources/bgp/subresources/rpki/subresources/aspa/methods/changes/) \- Retrieves changes to ASPA objects over time. * [/bgp/rpki/aspa/timeseries](https://developers.cloudflare.com/api/resources/radar/subresources/bgp/subresources/rpki/subresources/aspa/methods/timeseries/) \- Retrieves ASPA object counts over time as a timeseries. * Added ASPA deployment trend and objects count widgets to the [global routing page](https://radar.cloudflare.com/routing). * Added ASPA deployment rate widget to country and region routing pages. * Added ASPA-verified upstreams and change timeline to AS routing pages. ## 2026-02-12 **Add content type dimension to AI Bots** * Added new `content_type` dimension and filter to the AI Bots API: * [/ai/bots/summary/{dimension}](https://developers.cloudflare.com/api/resources/radar/subresources/ai/subresources/bots/methods/summary%5Fv2/) * [/ai/bots/timeseries\_groups/{dimension}](https://developers.cloudflare.com/api/resources/radar/subresources/ai/subresources/bots/methods/timeseries%5Fgroups/) * Added new **Content Type Distribution** chart to the [AI Insights page](https://radar.cloudflare.com/ai-insights#content-type). * Added content type chart to individual [bot information pages](https://radar.cloudflare.com/bots/directory) for AI crawlers. ## 2025-12-16 **New client type dimension in Web Crawlers and Mixed Purpose entry** * Added new Mixed Purpose entry to the `crawl_purpose` dimension of the [Web Crawlers](https://developers.cloudflare.com/api/resources/radar/subresources/bots/subresources/web%5Fcrawlers/) API, which as of this release includes Googlebot and Bingbot. * Added new dimension `client_type` to the [Web Crawlers](https://developers.cloudflare.com/api/resources/radar/subresources/bots/subresources/web%5Fcrawlers/) API. * Added new **HTML page requests by client type graph** to the [AI Insights page](https://radar.cloudflare.com/ai-insights#html-page-requests-by-client-type). ## 2025-11-24 **Add HTTP origins insights** * Added new [Origins](https://developers.cloudflare.com/api/resources/radar/subresources/origins/) API. * Extended [Annotations](https://developers.cloudflare.com/api/resources/radar/subresources/annotations/) and [Traffic Anomalies](https://developers.cloudflare.com/api/resources/radar/subresources/traffic%5Fanomalies/) APIs to support origin outages and anomalies. ## 2025-10-27 **Add TLD insights** * Added new dimensions `tld` and `tld_dns_magnitude` to the [DNS](https://developers.cloudflare.com/api/resources/radar/subresources/dns/) API. * Added new endpoints [/tlds](https://developers.cloudflare.com/api/resources/radar/subresources/tlds/methods/list/) and [/tlds/{tld}](https://developers.cloudflare.com/api/resources/radar/subresources/tlds/methods/get/). ## 2025-10-09 **Add CT log activity statistics** * Added new CT log activity stats to the [Get Certificate Log Details](https://developers.cloudflare.com/api/resources/radar/subresources/ct/subresources/logs/methods/get/) API response. ## 2025-10-06 **Add PQ encryption browser support check** * Added a [post-quantum encryption browser support check](https://radar.cloudflare.com/adoption-and-usage#browser-support) to the PQ encryption card in the Adoption & Usage section. ## 2025-09-29 **Add geolocation, ADM1 dimension to HTTP endpoints, and NetFlows endpoints** * Added new [geolocation endpoints](https://developers.cloudflare.com/api/resources/radar/subresources/geolocations/). * Added new ADM1 dimension to [HTTP](https://developers.cloudflare.com/api/resources/radar/subresources/http/) `summary` and `timeseries_groups` endpoints. * Added new [NetFlows](https://developers.cloudflare.com/api/resources/radar/subresources/netflows/) summary by dimension endpoint [summary\_v2](https://developers.cloudflare.com/api/resources/radar/subresources/netflows/methods/summary%5Fv2/). * Added new `geoId` filter to all [HTTP](https://developers.cloudflare.com/api/resources/radar/subresources/http/) and [NetFlows](https://developers.cloudflare.com/api/resources/radar/subresources/netflows/) endpoints. ## 2025-09-22 **Add IRR AS-SET membership lookup endpoint** * Added IRR AS-SET membership lookup endpoint * [ /entities/asns/{asn}/as\_set ](https://developers.cloudflare.com/api/resources/radar/subresources/entities/subresources/asns/methods/as%5Fset/) ## 2025-08-27 **Add industry and vertical to AI Bots and Web Crawlers, and bot kind to Bots** * Added vertical and industry dimensions/filters to: * [/ai/bots/summary/{dimension}](https://developers.cloudflare.com/api/resources/radar/subresources/ai/subresources/timeseries%5Fgroups/methods/summary/) * [/ai/bots/timeseries\_groups/{dimension}](https://developers.cloudflare.com/api/resources/radar/subresources/ai/subresources/timeseries%5Fgroups/methods/timeseries%5Fgroups/) * [/bots/crawlers/summary/{dimension}](https://developers.cloudflare.com/api/resources/radar/subresources/bots/subresources/web%5Fcrawlers/methods/summary/) * [/bots/crawlers/timeseries\_groups/{dimension}](https://developers.cloudflare.com/api/resources/radar/subresources/bots/subresources/web%5Fcrawlers/methods/timeseries%5Fgroups/) * Added bot kind dimension/filter to: * [/bots/summary/{dimension}](https://developers.cloudflare.com/api/resources/radar/subresources/bots/methods/summary/) * [/bots/timeseries\_groups/{dimension}](https://developers.cloudflare.com/api/resources/radar/subresources/bots/methods/timeseries%5Fgroups/) * Added new `botKind` filter to: * [/bots/timeseries](https://developers.cloudflare.com/api/resources/radar/subresources/bots/methods/timeseries/) * Added new `kind` property/filter to: * [/bots](https://developers.cloudflare.com/api/resources/radar/subresources/bots/methods/list/) * [/bots/{bot\_slug}](https://developers.cloudflare.com/api/resources/radar/subresources/bots/methods/get/) ## 2025-08-14 **Add AI Bots crawl purpose** * Added AI Bots crawl purpose dimension and filter to [summary](https://developers.cloudflare.com/api/resources/radar/subresources/ai/subresources/timeseries%5Fgroups/methods/summary/) and [timeseries\_groups](https://developers.cloudflare.com/api/resources/radar/subresources/ai/subresources/timeseries%5Fgroups/methods/timeseries%5Fgroups/) endpoints. ## 2025-08-06 **Add Certificate Transparency (CT) endpoints** * Added [CT endpoints](https://developers.cloudflare.com/api/resources/radar/subresources/ct/). ## 2025-07-01 **Add Bots and Web Crawlers endpoints** * Added new [bots endpoints](https://developers.cloudflare.com/api/resources/radar/subresources/bots/), replacing the deprecated verified bots endpoints. Use the following replacements: * `/verified_bots/top/bots` → `/bots/summary/bot` * `/verified_bots/top/categories` → `/bots/summary/bot_category` * Added [web crawlers endpoints](https://developers.cloudflare.com/api/resources/radar/subresources/bots/subresources/web%5Fcrawlers/). ## 2025-03-20 **Endpoint deprecations and new BGP real-time routes endpoint** * Deprecated endpoints for improved consistency (switch to the following): * `/attacks/layer3/top/industry` → [/attacks/layer3/summary/industry](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer3/subresources/summary/methods/industry/) * `/attacks/layer3/top/vertical` → [/attacks/layer3/summary/vertical](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer3/subresources/summary/methods/vertical/) * `/attacks/layer7/top/industry` → [/attacks/layer7/summary/industry](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer7/subresources/summary/methods/industry/) * `/attacks/layer7/top/vertical` → [/attacks/layer7/summary/vertical](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer7/subresources/summary/methods/vertical/) * Added the [BGP real-time routes endpoint](https://developers.cloudflare.com/api/resources/radar/subresources/bgp/subresources/routes/methods/realtime/). ## 2025-03-18 **Add leaked credential checks endpoints** * Added [leaked credential checks endpoints](https://developers.cloudflare.com/api/resources/radar/subresources/leaked%5Fcredentials/). ## 2025-02-27 **Add DNS endpoints** * Added [DNS endpoints](https://developers.cloudflare.com/api/resources/radar/subresources/dns/). ## 2025-02-04 **Add Internet services ranking, robots.txt, and AI inference endpoints** * Added [Internet services ranking endpoints](https://developers.cloudflare.com/api/resources/radar/subresources/ranking/subresources/internet%5Fservices/). * Added [robots.txt endpoints](https://developers.cloudflare.com/api/resources/radar/subresources/robots%5Ftxt/). * Added [AI inference endpoints](https://developers.cloudflare.com/api/resources/radar/subresources/ai/subresources/inference/). ## 2024-06-27 **Change TCP connection tampering API endpoints to TCP Resets Timeouts** * Changed the connection tampering summary and timeseries API endpoints to TCP resets timeouts [summary](https://developers.cloudflare.com/api/resources/radar/subresources/tcp%5Fresets%5Ftimeouts/methods/summary/)and [timeseries](https://developers.cloudflare.com/api/resources/radar/subresources/tcp%5Fresets%5Ftimeouts/methods/timeseries%5Fgroups/), respectively. ## 2023-11-27 **Add more meta information's** * Added meta.lastUpdated to all summaries and top endpoints (timeseries and timeseriesGroups already had this). * Fixed meta.dateRange to return date ranges for all requested series. ## 2023-11-16 **Add new layer 3 endpoints and layer 7 dimensions** * Added layer 3 [top origin locations](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer3/subresources/top/subresources/locations/methods/origin/)and [top target location](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer3/subresources/top/subresources/locations/methods/target/). * Added layer 7 Summaries by `http_method`, `http_version`, `ip_version`, `managed_rules`, `mitigation_product`. * Added layer 7 Timeseries Groups by `http_method`, `http_version`, `ip_version`, `managed_rules`, `mitigation_product`, `industry`, `vertical`. * Added layer 7 Top by `industry`, `vertical`. * Deprecated layer 7 timeseries groups without dimension. * To continue getting this data, switch to the new[timeseries group by mitigation\_product](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer7/subresources/timeseries%5Fgroups/methods/mitigation%5Fproduct/)endpoint. * Deprecated layer 7 summary without dimension. * To continue getting this data, switch to the new[summary by mitigation\_product](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer7/subresources/summary/methods/mitigation%5Fproduct/)endpoint. * Added new [Error codes](https://developers.cloudflare.com/radar/get-started/error-codes/). ## 2023-10-31 **Add new layer 3 direction parameter** * Added a `direction` parameter to all layer 3 endpoints. Use together with `location` parameter to filter by origin or target location [timeseries groups](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer3/subresources/timeseries%5Fgroups/methods/vector/). ## 2023-09-08 **Add Connection Tampering endpoints** * Added Connection Tampering [summary](https://developers.cloudflare.com/api/resources/radar/subresources/tcp%5Fresets%5Ftimeouts/methods/summary/)and [timeseries](https://developers.cloudflare.com/api/resources/radar/subresources/tcp%5Fresets%5Ftimeouts/methods/timeseries%5Fgroups/) endpoints. ## 2023-08-14 **Deprecate old layer 3 dataset** * Added Regional Internet Registry (see field `source` in response) to [get asn by id](https://developers.cloudflare.com/api/resources/radar/subresources/entities/subresources/asns/methods/get/)and [get asn by ip](https://developers.cloudflare.com/api/resources/radar/subresources/entities/subresources/asns/methods/ip/) endpoints. * Stopped collecting data in the old layer 3 data source. * Updated layer 3[timeseries](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer3/methods/timeseries/) endpoint to start using the new layer 3 data source by default, fetching the old data source now requires sending the parameter`metric=bytes_old`. * Deprecated layer 3 summary endpoint, this will stop receiving data after 2023-08-14. * To continue getting this data, switch to the new [timeseries group protocol](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer3/subresources/summary/methods/protocol/)endpoint. * Deprecated layer 3 timeseries groups endpoint, this will stop receiving data after 2023-08-14. * To continue getting this data, switch to the new [timeseries group protocol](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer3/subresources/timeseries%5Fgroups/methods/protocol/)endpoint. ## 2023-07-31 **Fix HTTP timeseries endpoint URLs** * Updated HTTP `timeseries` endpoints URLs to [timeseries\_groups](https://developers.cloudflare.com/api/resources/radar/subresources/http/subresources/timeseries%5Fgroups/)due to consistency. Old timeseries endpoints are still available, but will soon be removed. ## 2023-07-20 **Add URL Scanner endpoints** * Added [URL Scanner endpoints](https://developers.cloudflare.com/api/resources/url%5Fscanner/). For more information, refer to [URL Scanner](https://developers.cloudflare.com/radar/investigate/url-scanner/). ## 2023-06-20 **Add Internet quality endpoints** * Added [Internet quality endpoints](https://developers.cloudflare.com/api/resources/radar/subresources/quality/). ## 2023-06-07 **Add BGP stats, pfx2as and moas endpoints** * Added BGP [stats](https://developers.cloudflare.com/api/resources/radar/subresources/bgp/subresources/routes/methods/stats/),[pfx2as](https://developers.cloudflare.com/api/resources/radar/subresources/bgp/subresources/routes/methods/pfx2as/)and [moas](https://developers.cloudflare.com/api/resources/radar/subresources/bgp/subresources/routes/methods/moas/) endpoints. ## 2023-05-10 **Added \`IOS\` as an option for the OS parameter in all HTTP** * Added `IOS` as an option for the OS parameter in all HTTP endpoints ([example](https://developers.cloudflare.com/api/resources/radar/subresources/http/subresources/summary/methods/bot%5Fclass/)). ## 2023-03-20 **Add AS112 and email endpoints** * Added [AS112 endpoints](https://developers.cloudflare.com/api/resources/radar/subresources/as112/). * Added [email endpoints](https://developers.cloudflare.com/api/resources/radar/subresources/email/). ## 2023-01-23 **Updated IPv6 calculation method** * IPv6 percentage started to be calculated as (IPv6 requests / requests for dual-stacked content), where as before it was calculated as (IPv6 requests / IPv4+IPv6 requests). ## 2023-01-11 **Add new layer 3 dataset** * Added new layer 3 data source and related endpoints. * Updated layer 3[timeseries](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer3/methods/timeseries/) endpoint to support fetching both current and new data sources. For retro-compatibility reasons, fetching the new data source requires sending the parameter `metric=bytes` else the current data source will be returned. * Deprecated old layer 3 endpoints timeseries\_groups and summary. Users should upgrade to newer endpoints. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/release-notes/","name":"Release notes"}}]} ``` --- --- title: Aggregation intervals description: Aggregation intervals allow you to return data in a specified interval (or frequency). If no interval is defined, data will be returned in the default aggregation interval (or frequency). As a general principle, the longer the date range, the bigger the aggregation interval. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/concepts/aggregation-intervals.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # Aggregation intervals Aggregation intervals allow you to return data in a specified interval (or frequency). If no interval is defined, data will be returned in the default aggregation interval (or frequency). As a general principle, the longer the date range, the bigger the aggregation interval. For example, when requesting one day of data, the default aggregation interval is 15 minutes. When requesting more than one month of data, the default is one day. ## Method | Aggregation Interval | Description | | -------------------- | --------------------- | | 15m | 15 minutes frequency. | | 1h | One hour frequency. | | 1d | One day frequency. | | 1w | One week frequency. | ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/concepts/","name":"Concepts"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/concepts/aggregation-intervals/","name":"Aggregation intervals"}}]} ``` --- --- title: Bot classes description: A bot class in Radar is a grouping of bot scores. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/concepts/bot-classes.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # Bot classes A bot class in Radar is a grouping of [bot scores](https://developers.cloudflare.com/bots/concepts/bot-score). Scores between 1 and 29 are classified as bot traffic. Scores equal or above 30 are classified as non-bot/human traffic. | Class | Description | | -------------------- | ---------------------------- | | **Likely automated** | Bot scores of 1 through 29. | | **Likely human** | Bot scores of 30 through 99. | ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/concepts/","name":"Concepts"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/concepts/bot-classes/","name":"Bot classes"}}]} ``` --- --- title: Confidence levels description: The result.meta.confidenceInfo.level in the response provides an indication of how much confidence Cloudflare has in the data. Confidence levels can be affected either by internal issues affecting data quality or by not having a lot of data for a given location (like Antarctica) or Autonomous System (AS). image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/concepts/confidence-levels.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # Confidence levels The `result.meta.confidenceInfo.level` in the response provides an indication of how much confidence Cloudflare has in the data. Confidence levels can be affected either by internal issues affecting data quality or by not having a lot of data for a given location (like Antarctica) or Autonomous System (AS). | Level | Description | | ----- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1** | There is not enough data in this time range and/or for this location or Autonomous System. Data also exhibits an erratic pattern, possibly due to the reasons previously mentioned. | | **2** | There is not enough data in this timerange and/or in this location or Autonomous System. | | **3** | Data exhibits an erratic pattern but is not affected by known data issues (like pipeline issues). | | **4** | Unassigned. | | **5** | No known data quality issues. | ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/concepts/","name":"Concepts"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/concepts/confidence-levels/","name":"Confidence levels"}}]} ``` --- --- title: Normalization methods description: Cloudflare Radar does not normally return raw values. Instead, values are returned as percentages or normalized using min-max. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/concepts/normalization.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # Normalization methods Cloudflare Radar does not normally return raw values. Instead, values are returned as percentages or normalized using min-max. Refer to the `result.meta.normalization` property in the response to check which post-processing method was applied to the raw values, if any. ## Method | Method | Description | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | PERCENTAGE | Values represent percentages. | | PERCENTAGE\_CHANGE | Values represent a [percentage change ↗](https://en.wikipedia.org/wiki/Relative%5Fchange%5Fand%5Fdifference#Percentage%5Fchange) from a baseline period. | | OVERLAPPED\_PERCENTAGE | Values represent percentages that exceed 100% due to overlap. | | MIN\_MAX | Values have been normalized using [min-max ↗](https://en.wikipedia.org/wiki/Feature%5Fscaling#Rescaling%5F%28min-max%5Fnormalization%29). | | MIN0\_MAX | Values have been normalized using min-max, but setting the minimum value to 0. Equivalent to a proportion of the maximum value in the entire response, scaled between 0 and 1. | | RAW\_VALUES | Values are raw and have not been changed. | If you want to compare values across locations/time ranges/etc., in endpoints that normalize values using min-max, you must do so in the same request. This is done by asking for multiple series. All values will then be normalized using the same minimum and maximum value and can safely be compared against each other. Refer to [Make comparisons](https://developers.cloudflare.com/radar/get-started/making-comparisons/) for more information. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/concepts/","name":"Concepts"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/concepts/normalization/","name":"Normalization methods"}}]} ``` --- --- title: Configure alerts description: You can configure alerts to receive notifications when Radar detects changes impacting countries, regions, or autonomous systems. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/get-started/configure-alerts.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # Configure alerts You can configure alerts to receive notifications when Radar detects changes impacting countries, regions, or autonomous systems. Radar Alerts **Who is it for?** Customers who want to receive a notification when traffic anomalies, outages, route hijacks, or route leaks are impacting one or more countries, regions, or autonomous systems (ASNs) of interest. **Other options / filters** Filters include: * Notification type (anomaly, outage, route hijack, route leak) * Location (country or region) * Autonomous systems (ASNs) You have the option to send the notification via email, webhook, or PagerDuty. **Included with** All Cloudflare plans. **What should you do if you receive one?** Further action will depend on your role. Refer to the [Radar documentation](https://developers.cloudflare.com/radar/) for more information. Refer to [Cloudflare Notifications](https://developers.cloudflare.com/notifications/get-started/) for more information on how to set up an alert. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/get-started/","name":"Get started"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/get-started/configure-alerts/","name":"Configure alerts"}}]} ``` --- --- title: Share a Radar chart description: Radar allows you to download an image of a chart, as well as embed interactive cards of most charts into your own web pages. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/get-started/embed.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # Share a Radar chart Radar allows you to download an image of a chart, as well as embed interactive cards of most charts into your own web pages. Charts supporting this feature will have a share icon next to its description. ## Download a chart in PNG format 1. Select the Share icon next to the description of the chart you wish to share. 2. Select `Download Image.` 3. A .png file containing the requested chart will be downloaded. ## Embed an interactive chart in your website 1. Select the Share icon next to the description of the chart you wish to share. 2. Select between Fixed Time and Real Time. * Real Time uses a “sliding window” based on the selected date range, and will display data points looking back over that duration from the current date/time. * Fixed Time will always display a chart with only the currently visible data points. 3. Select Copy Code and paste the code into your web page. **Note**: Your current selections, such as date range, location, autonomous system (ASN), and visible series, will be reflected in the shared chart. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/get-started/","name":"Get started"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/get-started/embed/","name":"Share a Radar chart"}}]} ``` --- --- title: Radar API error codes image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/get-started/error-codes.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # Radar API error codes | Error Code | HTTP Status Code | Description | | ---------- | ---------------- | ----------------------- | | 2000 | 500 | Internal Error | | 2001 | 400 | Input Validation Error | | 2002 | 422 | Query is above max cost | | 1015 | 429 | Too many requests | | 7003 | 404 | Not found | ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/get-started/","name":"Get started"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/get-started/error-codes/","name":"Radar API error codes"}}]} ``` --- --- title: Make your first API request image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/get-started/first-request.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # Make your first API request To make your first request to Cloudflare's Radar API, you must obtain your [API token](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/) first. Create a Custom Token, with _Account_ \> _Radar_ in the **Permissions** group, and select _Read_ as the access level. Once you have the token, you are ready to make your first request to Radar's API at `https://api.cloudflare.com/client/v4/radar/`. ## Example using cURL In the following example, we will access the global percentage distribution of device types (like mobile and desktop traffic) for the last seven days. For more information, refer to [Get device types summary](https://developers.cloudflare.com/api/resources/radar/subresources/http/subresources/summary/methods/device%5Ftype/) endpoint: Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/http/summary/device_type?dateRange=7d&format=json" \ --header "Authorization: Bearer " ``` A successful response will look similar to the following: ``` { "success": true, "errors": [], "result": { "summary_0": { "desktop": "58.223483", "mobile": "41.725833", "other": "0.050684" }, "meta": { "dateRange": { "startTime": "2022-10-26T14:00:00Z", "endTime": "2022-11-02T14:00:00Z" }, "normalization": "PERCENTAGE", ... } } } ``` This response means that 41% of the requests are classified as coming from mobile devices, while 58% are desktop traffic. Note Cloudflare Radar attempts to provide trends and insights into general Internet usage, using the traffic that goes through Cloudflare infrastructure. As such, Cloudflare Radar only provides data on traffic coming from end-users, unless otherwise specified (for example, origin fetches are excluded). The previous example returns all traffic from bots and humans. However, you can access just the traffic classified as coming from humans (the default in [Cloudflare Radar ↗](https://radar.cloudflare.com)) by adding `botClass=LIKELY_HUMAN`. You can also access traffic coming only from bots with `botClass=LIKELY_AUTOMATED` (refer to [bot classes](https://developers.cloudflare.com/radar/concepts/bot-classes) for more information). For example: Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/http/summary/device_type?dateRange=7d&botClass=LIKELY_AUTOMATED&format=json" \ --header "Authorization: Bearer " ``` Running the above, can you find any differences between both in the distribution of mobile versus desktop traffic? The `result.meta` property The `result.meta` property in the response includes metadata about the current request. In the example above, `meta.dateRange` returns the date range specified in the query, while `meta.normalization` returns the type of normalization applied to the data (refer to [Normalization methods](https://developers.cloudflare.com/radar/concepts/normalization) for more information). When querying for time series, `result.meta` will also include the returned [aggregation interval](https://developers.cloudflare.com/radar/concepts/aggregation-intervals) in `meta.aggInterval`. When present, `meta.confidenceInfo.level` will also provide an indication of how much confidence Cloudflare has in the data. Confidence levels are affected either by internal issues affecting data quality or by Cloudflare not having sufficient data for a given location or Autonomous System (AS). In these cases, confidence level will be below `5` (refer to [Confidence levels](https://developers.cloudflare.com/radar/concepts/confidence-levels) for more information). ## Use Python [Python ↗](https://www.python.org/) has become one of the standard languages in data analysis. Here is a quick example on how to chart the same data using [Requests ↗](https://pypi.org/project/requests/) and [Pandas ↗](https://pandas.pydata.org/) libraries. Here, we are using `format=csv` in the parameters to make it easier for Pandas to import. Python ``` import io import requests import pandas as pd cf_api_url = "https://api.cloudflare.com/client/v4" params = "dateRange=7d&format=csv" my_token = "xxx" # TODO replace r = requests.get(f"{cf_api_url}/radar/http/summary/device_type?{params}", headers={"Authorization": f"Bearer {my_token}"}) df = pd.read_csv(io.StringIO(r.text)) df.plot(kind="bar", stacked=True) ``` ### Notebooks A [notebook ↗](https://jupyter.org/) is a web-based interactive computing application, where text, code, and code outputs, like charts, can be combined into a single document. Refer to Radar's companion [colaboratory notebook ↗](https://colab.research.google.com/github/cloudflare/radar-notebooks/blob/main/notebooks/example.ipynb) for more examples on how the API can be used in your own projects. ## Next steps Refer to [Make comparisons](https://developers.cloudflare.com/radar/get-started/making-comparisons/) to learn how to compare data. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/get-started/","name":"Get started"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/get-started/first-request/","name":"Make your first API request"}}]} ``` --- --- title: Make comparisons description: When comparing time series, across locations/time ranges/etc., in endpoints that normalize values using min-max, you must do so in the same request. This is done by asking for multiple series. All values will then be normalized using the same minimum and maximum value and can safely be compared against each other. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/get-started/making-comparisons.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # Make comparisons When comparing time series, across locations/time ranges/etc., in endpoints that normalize values using [min-max](https://developers.cloudflare.com/radar/concepts/normalization), you must do so in the same request. This is done by asking for multiple series. All values will then be normalized using the same minimum and maximum value and can safely be compared against each other. [NetFlows](https://developers.cloudflare.com/radar/investigate/netflows) values are normalized using [min0-max](https://developers.cloudflare.com/radar/concepts/normalization), so we will use it as an example. Refer to [Get NetFlow time series](https://developers.cloudflare.com/api/resources/radar/subresources/netflows/methods/timeseries/) for more information. ## Compare locations In the following example, we will compare the traffic change across two different locations — United States and Portugal. The example will use [alpha-2 codes ↗](https://en.wikipedia.org/wiki/ISO%5F3166-1%5Falpha-2#Officially%5Fassigned%5Fcode%5Felements) for the last seven days: Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/netflows/timeseries?name=us_data&dateRange=7d&location=US&name=pt_data&dateRange=7d&location=PT&format=json" \ --header "Authorization: Bearer " ``` In the example above we are asking for two timeseries. The first series has the following parameters: `name=us_data&dateRange=7d&location=US` The second series has the following parameters: `name=pt_data&dateRange=7d&location=PT` All of these parameters are arrays, and it is the position in the array that defines the series the filter belongs to. Refer to [NetFlow's endpoint](https://developers.cloudflare.com/api/resources/radar/subresources/netflows/methods/timeseries/) for more information on the available parameters. The response (shortened below for brevity) uses the provided `name` property to wrap the timestamps and corresponding values. If we chart this data, it becomes obvious that Cloudflare received much less traffic from Portugal than from the United States. ``` { "success": true, "errors": [], "result": { "us_data": { "timestamps": [ "2022-10-26T17:00:00Z", "2022-11-02T15:00:00Z" ], "values": [ "0.871752", "1" ] }, "pt_data": { "timestamps": [ "2022-10-26T17:00:00Z", "2022-11-02T15:00:00Z" ], "values": [ "0.020457", "0.012313" ] }, "meta": { "dateRange": { "startTime": "2022-10-26T17:00:00Z", "endTime": "2022-11-02T17:00:00Z" }, "aggInterval": "ONE_HOUR", // ... } } } ``` Comparisons can be made in most endpoints, not just endpoints that use `min-max`. ## Compare date ranges In the next example, we will compare the United States across different date ranges using the shortcuts `7d` and `7dControl`. These mean the last seven days and the last seven days before those, respectively — or, in other words, this week versus the previous week. Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/netflows/timeseries?name=this_week&dateRange=7d&location=US&name=previous_week&dateRange=7dControl&location=US&format=json" \ --header "Authorization: Bearer " ``` The first series has these parameters: `name=this_week&dateRange=7d&location=US` The second series has the following parameters: `name=previous_week&dateRange=7dControl&location=US` Now, in the `result` property, you should get something like this: ``` { "this_week": { "timestamps": [ "2022-10-27T13:00:00Z", "2022-10-27T14:00:00Z", "...", "2022-11-03T12:00:00Z" ], "values": [ "0.794321", "1", "...", "0.718433"] }, "previous_week": { "timestamps": [ "2022-10-20T13:00:00Z", "2022-10-20T14:00:00Z", "...", "2022-10-27T12:00:00Z" ], "values": [ "0.774392", "0.835071", "...", "0.720181"] } } ``` Examining this information, we can conclude that the maximum value was reached at `2022-10-27T14:00:00Z` (all Radar timestamps are in Coordinated Universal Time (UTC)). We can also check what the date range shortcuts `7d` and `7dControl` were resolved to at the time this was run. ### Use specific timestamps You can also request for specific timestamps. In the following example, we will ask for data relative to [Tonga ↗](https://blog.cloudflare.com/tonga-internet-outage/) in October versus January 2022, when there was an outage. Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/netflows/timeseries?name=tonga&dateStart=2022-10-15T02%3A00%3A00Z&dateEnd=2022-10-15T05%3A00%3A00Z&location=TO&name=tonga_outage&dateStart=2022-01-15T02%3A00%3A00Z&dateEnd=2022-01-15T05%3A00%3A00Z&location=TO&format=json&aggInterval=1h" \ --header "Authorization: Bearer " ``` The first series has these parameters (URL encoded): `name=tonga&dateStart=2022-10-15T02%3A00%3A00Z&dateEnd=2022-10-15T05%3A00%3A00Z%&location=TO` The second series has these parameters: `name=tonga_outage&dateStart=2022-01-15T02%3A00%3A00Z&&dateEnd=2022-01-15T05%3A00%3A00Z&location=TO` In the above example, we requested for an [aggregation interval](https://developers.cloudflare.com/radar/concepts/aggregation-intervals) of one hour (`aggInterval=1h`), so that the results could be shown in this page. `format` and `aggInterval` are not arrays, as specified in the [API reference](https://developers.cloudflare.com/api/resources/radar/subresources/netflows/methods/timeseries/), and apply globally to all series in the request. The `result` property should return a response like this: ``` { "tonga": { "timestamps": ["2022-10-15T02:00:00Z", "2022-10-15T03:00:00Z", "2022-10-15T04:00:00Z", "2022-10-15T05:00:00Z"], "values": ["1.0", "0.832473", "0.820083", "0.79408"] }, "tonga_outage": { "timestamps": ["2022-01-15T02:00:00Z", "2022-01-15T03:00:00Z", "2022-01-15T04:00:00Z", "2022-01-15T05:00:00Z"], "values": ["0.354105", "0.357287", "0.181811", "0.044198"] } } ``` This shows how traffic dropped to almost zero during the outage. If we chart it and set the end date to January 18 to make it clearer, we get the following: ![Tonga October vs January 2022](https://developers.cloudflare.com/_astro/tonga_outage.DWg4Our9_2cJMzr.webp) ## Next steps Refer to the Investigate section to drill down on the data Radar returns, such as [NetFlows](https://developers.cloudflare.com/radar/investigate/netflows). ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/get-started/","name":"Get started"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/get-started/making-comparisons/","name":"Make comparisons"}}]} ``` --- --- title: Application layer attacks description: While in HTTP requests you can examine all kinds of web requests, in application layer attacks you have access only to mitigated HTTP requests. These requests can be mitigated by one of several Cloudflare products, like WAF, Cloudflare DDoS Protection, Cloudflare bot solutions and others. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/investigate/application-layer-attacks.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # Application layer attacks While in [HTTP requests](https://developers.cloudflare.com/radar/investigate/http-requests) you can examine all kinds of web requests, in application layer attacks you have access only to mitigated HTTP requests. These requests can be mitigated by one of several Cloudflare products, like [WAF](https://developers.cloudflare.com/waf/), [Cloudflare DDoS Protection](https://developers.cloudflare.com/ddos-protection/), [Cloudflare bot solutions](https://developers.cloudflare.com/bots/) and others. Mitigated traffic Mitigated traffic is any HTTP request from an end-user that has a terminating action applied by the Cloudflare platform. These include actions like `BLOCK` or [challenges](https://developers.cloudflare.com/cloudflare-challenges/). Since we are examining attacks, we can inspect both sides of an attack — both the source location and the target location of the attack. For the source of the attack Cloudflare uses the location the attack is coming from associated with the IP (note that the human orchestrator of the attack may be in a different location than the computer the attack is originating from). For the target location of the attacks, Cloudflare uses the billing location associated with the zone under attack. This ability to filter by both sides of the attack is only available in the `top locations` endpoints. Unless otherwise specified, other endpoints are filtered by source location, like the origin location of the attack. The magnitude of the attack is defined by the total number of mitigated requests. Like in [HTTP requests](https://developers.cloudflare.com/radar/investigate/http-requests), these endpoints can be split into the ability to fetch a timeseries, a single value summarizing the entire date range, and a list of top locations. ## List of endpoints ### Timeseries #### Example: Hourly mitigation requests by product Let us examine the global distribution of mitigated requests by product. Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/attacks/layer7/timeseries_groups/mitigation_product?aggInterval=1h&dateRange=1d&name=attacks&format=json" \ --header "Authorization: Bearer " ``` From the abbreviated response below, we can conclude that distributed denial-of-service (DDoS) attacks make up the majority of the requests — which makes sense since DDoS attacks, by their very nature, will perform more requests. This is followed by WAF and then I reputation requests. ``` { "success": true, "errors": [], "result": { "attacks": { "timestamps": ["2022-11-05T11:00:00Z", ".."], "ddos": ["53.824302", "54.305823", ".."], "waf": ["39.760956", "39.31228", ".."], "ip_reputation": ["5.623487", "5.485468", ".."], "access_rules": ["0.648368", "0.676456", ".."], "bot_management": ["0.139733", "0.217155", ".."], "api_shield": ["0.003154", "0.002819", ".."], "data_loss_prevention": ["0.0", "0.0", ".."] }, "meta": { "dateRange": { "startTime": "2022-11-05T11:00:00Z", "endTime": "2022-11-06T11:00:00Z" }, // ... } } } ``` For more information refer to [Get layer 7 attacks by mitigation technique, over time](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer7/subresources/timeseries%5Fgroups/). ### Summary #### Example: Mitigation requests by product We can also filter by source location and examine attacks coming from a specific place - in the following example, we examine attacks coming from Great Britain: Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/attacks/layer7/summary?location=GB&name=attacks_gb&aggInterval=1h&dateRange=1d&format=json" \ --header "Authorization: Bearer " ``` ``` { "success": true, "errors": [], "result": { "attacks_gb": { "waf": "75.012138", "ddos": "18.539149", "ip_reputation": "5.721021", "access_rules": "0.592515", "bot_management": "0.131998", "api_shield": "0.003178", "data_loss_prevention": "0.0" }, "meta": { // ... } } } ``` This response means that 75% of all mitigated requests coming from Great Britain were mitigated by the [WAF](https://developers.cloudflare.com/waf/) product. For more information refer to [Get layer 7 attacks summary](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer7/subresources/summary/methods/get/). ### Top #### Example: Top target locations In the following example, we will examine the top locations being targeted in application layer attacks, in the last 24 hours: Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/attacks/layer7/top/locations/target?name=attacks_target&limit=5&dateRange=1d&format=json" \ --header "Authorization: Bearer " ``` ``` { "success": true, "errors": [], "result": { "attacks_target": [ { "targetCountryName": "Belgium", "targetCountryAlpha2": "BE", "value": "18.536740", "rank": 1 }, { "targetCountryName": "United States", "targetCountryAlpha2": "US", "value": "16.116210", "rank": 2 }, { "targetCountryName": "China", "targetCountryAlpha2": "CN", "value": "13.864696", "rank": 3 }, { "targetCountryName": "India", "targetCountryAlpha2": "IN", "value": "4.344139", "rank": 4 }, { "targetCountryName": "Germany", "targetCountryAlpha2": "DE", "value": "4.182777", "rank": 5 } ], "meta": { "dateRange": { "startTime": "2022-11-05T12:00:00Z", "endTime": "2022-11-06T12:00:00Z" }, // ... } } } ``` During the specified date range, mitigation requests to zones with a billing address located in Belgium represent 18%. For more information refer to [Get layer 7 top target locations](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer7/subresources/top/subresources/locations/methods/target/). #### Example: Top attacks Which source-target location pairs constitute the biggest attacks in the last 24 hours? Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/attacks/layer7/top/attacks?limit=5&dateRange=1d&format=json" \ --header "Authorization: Bearer " ``` A typical response will be similar to the following: ``` { "success": true, "errors": [], "result": { "top_0": [ { "originCountryName": "United States", "originCountryAlpha2": "US", "targetCountryName": "United States", "targetCountryAlpha2": "US", "value": "3.790724", "rank": 1 }, { "originCountryName": "United States", "originCountryAlpha2": "US", "targetCountryName": "Belgium", "targetCountryAlpha2": "BE", "value": "3.602177", "rank": 2 }, { "originCountryName": "China", "originCountryAlpha2": "CN", "targetCountryName": "Netherlands", "targetCountryAlpha2": "NL", "value": "3.017341", "rank": 3 }, { "originCountryName": "China", "originCountryAlpha2": "CN", "targetCountryName": "China", "targetCountryAlpha2": "CN", "value": "2.472068", "rank": 4 }, { "originCountryName": "Indonesia", "originCountryAlpha2": "ID", "targetCountryName": "China", "targetCountryAlpha2": "CN", "value": "2.056729", "rank": 5 } ], "meta": { // ... } } } ``` This means that 3.79% of all mitigated requests are from and to the US, 3.6% of all mitigated requests are from the US to Belgium, etc.. For more information refer to [Get layer 7 top attack pairs](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer7/subresources/top/methods/attacks/). ## Next steps Refer to [Network layer attacks](https://developers.cloudflare.com/radar/investigate/network-layer-attacks/) for more information on data on layer 3 of the Open Systems Interconnection (OSI) model. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/investigate/","name":"Investigate"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/investigate/application-layer-attacks/","name":"Application layer attacks"}}]} ``` --- --- title: BGP anomalies description: To access Cloudflare Radar BGP Anomaly Detection results, you will first need to create an API token that includes a Account:Radar permission. All the following examples should work with a free-tier Cloudflare account. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/investigate/bgp-anomalies.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # BGP anomalies To access Cloudflare Radar BGP Anomaly Detection results, you will first need to create an API token that includes a `Account:Radar` permission. All the following examples should work with a free-tier Cloudflare account. ## Search BGP hijack events In the following example, we will query the [BGP hijack events API](https://developers.cloudflare.com/api/resources/radar/subresources/bgp/subresources/hijacks/subresources/events/methods/list/) for the most recent BGP origin hijacks originated by or affecting `AS64512` (example ASN). Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/bgp/hijacks/events?invlovedAsn=64512&format=json&per_page=10" \ --header "Authorization: Bearer " ``` The result shows the most recent 10 BGP hijack events that affects `AS64512`. ``` { "success": true, "errors": [], "result": { "asn_info": [ { "asn": 64512, "org_name": "XXXXX", "country_code": "XX" }, ... ], "events": [ { "duration": 0, "event_type": 0, "hijack_msgs_count": 1, "hijacker_asn": 64512, "id": 1234, "is_stale": false, "max_hijack_ts": "2023-04-27T14:01:55.952", "max_msg_ts": "2023-04-27T14:01:55.952", "min_hijack_ts": "2023-04-27T14:01:55.952", "on_going_count": 1, "peer_asns": [ 8455 ], "peer_ip_count": 1, "prefixes": [ "192.0.2.0/24" ], "tags": [ { "name": "irr_new_origin_invalid", "score": 4 }, { "name": "irr_old_origin_valid", "score": 0 }, ... ], "victim_asns": [ 64513 ], "confidence_score": 4 }, ], "total_monitors": 163 }, ... } ``` In the response we can learn about the following information about each event: * `hijack_msg_count`: the number of potential BGP hijack messages observed from all peers. * `peer_asns`: the AS numbers of the route collector peers who observed the hijack messages. * `prefixes`: the affected prefixes. * `hijacker_asn` and `victim_asns`: the potential hijacker ASN and victim ASNs. * `confidence_score`: a quantitative score describing how confident the system is for this event being a hijack: * 1-3: low confidence. * 4-7: medium confidence. * 8-above: high confidence. * `tags`: the evidence collected for the events. Each `tag` is also associated with a score that affects the overall confidence score: * a positive score indicates that the event is _more likely_ to be a hijack. * a negative score indicates that the event is _less likely_ to be a hijack. Users can further filter out low-confidence events by attaching a `minConfidence=8` parameter, which will return only events with a `confidence_score` of `8` or higher. Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/bgp/hijacks/events?invlovedAsn=64512&format=json&per_page=10&minConfidence=8" \ --header "Authorization: Bearer " ``` ## Search BGP route leak events BGP route leak is another type of BGP anomalies that Cloudflare Radar detects. Currently, we focus on detecting specifically the `provider-customer-provider` type of route leak. You can learn more about our design and methodology in [our blog post ↗](https://blog.cloudflare.com/route-leak-detection-with-cloudflare-radar/). In the following example, we will query the [BGP route leak events API](https://developers.cloudflare.com/api/resources/radar/subresources/bgp/subresources/leaks/subresources/events/methods/list/) for the most recent BGP route leak events affecting `AS64512`. Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/bgp/leaks/events?invlovedAsn=64512&format=json&per_page=10" \ --header "Authorization: Bearer " ``` The result shows the most recent 10 BGP route leak events that affects `AS64512`. ``` { "success": true, "errors": [], "result": { "asn_info": [ { "asn": 64512, "org_name": "XXXXXXX", "country_code": "XX" }, ... ], "events": [ { "detected_ts": "2023-04-21T23:10:06", "finished": false, "id": 1234, "leak_asn": 64512, "leak_count": 14, "leak_seg": [ 64514, 64512, 64513 ], "leak_type": 1, "max_ts": "2023-04-21T23:10:56", "min_ts": "2023-04-21T23:09:46", "origin_count": 1, "peer_count": 13, "prefix_count": 1 }, ... ] }, ... } ``` In the response we can learn about the following information about each event: * `leak_asn`: the AS who potentially caused the leak. * `leak_seg`: the AS path segment observed and believed to be a leak. * `min_ts` and `max_ts`: the earliest and latest timestamps of the leak announcements. * `leak_count`: the total number of BGP route leak announcements observed. * `peer_count`: the number of route collector peers observed the leak. * `prefix_count` and `origin_count`: the number of prefixes and origin ASes affected by the leak. ## Send alerts for BGP hijacks In this example, we will show you how you can build a Cloudflare Workers app that sends out alerts for BGP hijacks relevant to a given ASN using webhooks (works for Google Hangouts, Discord, Telegram, etc) or email. We will use Cloudflare Workers as the platform and use its Cron Triggers to periodically check for new alerts. For the app, we would like it to do the following things: * Fetch from Cloudflare API with a given API token. * Check against Cloudflare KV to know what events are new. * Construct messages for new hijacks and send out alerts via webhook triggers. ### Worker app setup We will start with setting up a Cloudflare Worker app. First, create a new Workers app in a local directory: npm yarn pnpm ``` npm create cloudflare@latest -- hijack-alerts ``` ``` yarn create cloudflare hijack-alerts ``` ``` pnpm create cloudflare@latest hijack-alerts ``` For setup, select the following options: * For _What would you like to start with?_, choose `Hello World example`. * For _Which template would you like to use?_, choose `Worker only`. * For _Which language do you want to use?_, choose `JavaScript`. * For _Do you want to use git for version control?_, choose `Yes`. * For _Do you want to deploy your application?_, choose `No` (we will be making some changes before deploying). To start developing your Worker, `cd` into your new project directory: Terminal window ``` cd hijack-alerts ``` In your Wrangler file, change the default checking frequency (once per hour) to what you like. Here is an example of configuring the workers to run the script five minutes. * [ wrangler.jsonc ](#tab-panel-5957) * [ wrangler.toml ](#tab-panel-5958) ``` { "$schema": "./node_modules/wrangler/config-schema.json", "name": "hijack-alerts", "main": "src/index.js", // Set this to today's date "compatibility_date": "2026-04-03", "triggers": { "crons": [ "*/5 * * * *" ] } } ``` ``` "$schema" = "./node_modules/wrangler/config-schema.json" name = "hijack-alerts" main = "src/index.js" # Set this to today's date compatibility_date = "2026-04-03" [triggers] crons = [ "*/5 * * * *" ] ``` In this example, we will also need to use Cloudflare KV to save the latest checked event IDs which allows us to know what events are new. Once you have created a KV, you can head back to the `wrangler.jsonc` file and add the following sections: * [ wrangler.jsonc ](#tab-panel-5955) * [ wrangler.toml ](#tab-panel-5956) ``` { "kv_namespaces": [ { "binding": "HIJACKS_KV", "id": "KV_ID_FOR_PRODUCTION", "preview_id": "TEMPORARY_KV_FOR_DEV_ENVIRONMENT" } ] } ``` ``` [[kv_namespaces]] binding = "HIJACKS_KV" id = "KV_ID_FOR_PRODUCTION" preview_id = "TEMPORARY_KV_FOR_DEV_ENVIRONMENT" ``` ### Fetch for newly detected BGP hijacks Start with the API fetching function. The following `apiFetch(env, paramsStr)` handles taking in a request parameters string, construct proper headers and fetch from the Cloudflare API BGP hijacks endpoint. JavaScript ``` async function apiFetch(env, paramsStr) { const config = { headers: { Authorization: `Bearer ${env.CF_API_TOKEN}`, }, }; const res = await fetch( `https://api.cloudflare.com/client/v4/radar/bgp/hijacks/events?${paramsStr}`, config, ); if (!res.ok) { console.log(JSON.stringify(res)); return null; } return await res.json(); } ``` The `env` parameter is passed in from the caller, and we do not need to worry about construct it. The `paramsStr` is a string variable that holds the query parameters in a query URL. Now in our main cron trigger function, we will need to construct the query parameters and call the API fetch function. The default cron trigger worker script is defined as the follows: JavaScript ``` export default { async scheduled(controller, env, ctx) { ... } } ``` In our example, we use the `env` variables to get the runtime variables like the TOKEN and ASN of interest, and Cloudflare KV bindings. We do not use the `controller` and `ctx` variables in this example. First, we will need to learn about what are the new events. We define new events as the events the app has not yet processed. We use the Cloudflare KV bucket previously created and defined (`HIJACKS_KV`) to save and retrieve the most recent processed event ID. JavaScript ``` let kv_latest_id = parseInt(await env.HIJACKS_KV.get("latest_id")); const first_batch = isNaN(kv_latest_id); ``` The main loop that checks for the most recent events looks like this (some of the validation code is skipped): JavaScript ``` let new_events = []; let page = 1; while (true) { // query for events const query_params = `per_page=10&page=${page}&involvedAsn=${env.TARGET_ASN}&sortBy=ID&sortOrder=DESC`; const data = await apiFetch(env, query_params); // first batch, save KV value only if (first_batch) { await env.HIJACKS_KV.put("latest_id", events[0].id.toString()); return; } // some validation skipped // ... let reached_last = false; for (const event of data.result.events) { if (event.id <= kv_latest_id) { // reached the latest events reached_last = true; break; } new_events.push(event); } if (reached_last) { break; } page += 1; } ``` Now that we have all the newly detected events saved in `new_events` variable, we can then send out alerts: JavaScript ``` // sort events by increasing ID order new_events.sort((a, b) => a.id - b.id); const kv_latest_id = new_events[new_events.length - 1].id; // push new events for (const event of new_events) { await send_alert(env, event); } // update latest_id KV value await env.HIJACKS_KV.put("latest_id", kv_latest_id.toString()); ``` ### Send alerts using webhook The function `send_alert` handles constructing alert message and sending out alerts using webhook. Here we demonstrate an example plain-text message template using Google Hangouts webhook. Users can customize the message and the use of webhook based on their platform of choice and needs. JavaScript ``` async function send_hangout_alert(env, event) { const webhook_url = `${env.WEBHOOK_URL}&threadKey=bgp-hijacks-event-${event.id}`; const data = JSON.stringify({ text: `Detected BGP hijack event (${event.id}): Detected time: *${event.min_hijack_ts} UTC* Detected ASN: *${event.hijacker_asn}* Expected ASN(s): *${event.victim_asns.join(" ")}* Prefixes: *${event.prefixes.join(" ")}* Tags: *${event.tags.map((tag) => tag.name).join(" ")}* Peer Count: *${event.peer_ip_count}* `, }); await fetch(webhook_url, { method: "POST", headers: { "Content-Type": "application/json; charset=UTF-8", }, body: data, }); } ``` Note that the webhook is considered secret and should be set to the environment via `wrangler secret put WEBHOOK_URL` command. The last step is to deploy the application with command `npx wrangler deploy` and the app should be up and running on your Cloudflare account, and will be triggered to execute every five minutes. ### Send email alerts from Workers If you have [Email Routing](https://developers.cloudflare.com/email-routing/) enabled for your domain, you can also send email alerts directly from Workers. Refer to [Send emails from Workers](https://developers.cloudflare.com/email-routing/email-workers/send-email-workers/) to learn more. For this alert to work, you will need to configure the proper email bindings in the [Wrangler configuration file](https://developers.cloudflare.com/workers/wrangler/configuration/#email-bindings). * [ wrangler.jsonc ](#tab-panel-5959) * [ wrangler.toml ](#tab-panel-5960) ``` { "send_email": [ { "type": "send_email", "name": "SEND_EMAIL_BINDING", "destination_address": "@example.com" } ] } ``` ``` [[send_email]] type = "send_email" name = "SEND_EMAIL_BINDING" destination_address = "@example.com" ``` Then, you can create an email-sending function to send alert emails to your configured destination address: JavaScript ``` async function send_email_alert(hijacker, prefixes, victims) { const msg = createMimeMessage(); msg.setSender({ name: "BGP Hijack Alerter", addr: "@", }); msg.setRecipient("@example.com"); msg.setSubject("BGP hijack alert"); msg.addMessage({ contentType: "text/plain", data: `BGP hijack detected: Detected origin: ${hijacker} Expected origins: ${victims.join(" ")} Prefixes: ${prefixes.join(" ")} `, }); var message = new EmailMessage( "@", "@example.com", msg.asRaw(), ); try { await env.SEND_EMAIL_BINDING.send(message); } catch (e) { return new Response(e.message); } } ``` ## Next steps Refer to our API documentation for [BGP route leaks](https://developers.cloudflare.com/api/resources/radar/subresources/bgp/subresources/leaks/subresources/events/methods/list/) and [BGP hijacks](https://developers.cloudflare.com/api/resources/radar/subresources/bgp/subresources/hijacks/subresources/events/methods/list/) for more information on these topics. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/investigate/","name":"Investigate"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/investigate/bgp-anomalies/","name":"BGP anomalies"}}]} ``` --- --- title: DNS description: Access aggregated and anonymized DNS queries to Cloudflare's 1.1.1.1 public resolver service. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/investigate/dns.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # DNS Access aggregated and anonymized DNS queries to Cloudflare's [1.1.1.1](https://developers.cloudflare.com/1.1.1.1/) public resolver service. ## List of endpoints ### Top locations #### Example: Geographical distribution of `google.com` versus `yandex.ru` In the next example, we will request the top originating locations for `google.com` DNS queries: Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/dns/top/locations?domain=google.com&dateRange=1d&format=json&limit=2" \ --header "Authorization: Bearer " ``` The response shows that most queries come from the United States and Brazil: ``` { "success": true, "errors": [], "result": { "top_0": [ { "clientCountryAlpha2": "US", "clientCountryName": "United States", "value": "43.474518" }, { "clientCountryAlpha2": "BR", "clientCountryName": "Brazil", "value": "10.772799" } ], "meta": { // ... } } } ``` Making the same search request for `yandex.ru`, a Russian search engine: Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/dns/top/locations?domain=yandex.ru&dateRange=1d&format=json&limit=2" \ --header "Authorization: Bearer " ``` Returns the following response: ``` { "success": true, "errors": [], "result": { "top_0": [ { "clientCountryAlpha2": "RU", "clientCountryName": "Russian Federation", "value": "73.710495" }, { "clientCountryAlpha2": "DE", "clientCountryName": "Germany", "value": "5.518052" } ], "meta": { // ... } } } ``` As expected, most queries come from Russia. Note Note that these examples return the total number of DNS queries from a location to a hostname, _out_ of the total DNS queries to a given hostname. In this sense, it is expected that locations with higher population numbers — like the United States — frequently appear in the top spots, even if the actual percentage is low. You can also provide multiple hostnames. Refer to [Get DNS top locations](https://developers.cloudflare.com/api/resources/radar/subresources/dns/subresources/top/methods/locations/) for more information. This is useful when the application you want to explore uses several hostnames to serve its content (like a hostname for the main website, another hostname dedicated to its API, etc.). ## Next steps Refer to [Domain ranking](https://developers.cloudflare.com/radar/investigate/domain-ranking-datasets/) for more information on rankings generated by Cloudflare based on DNS queries to [1.1.1.1 public resolver](https://developers.cloudflare.com/1.1.1.1/). ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/investigate/","name":"Investigate"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/investigate/dns/","name":"DNS"}}]} ``` --- --- title: Domains ranking description: Cloudflare regularly generates a domain ranking based on DNS queries to 1.1.1.1, Cloudflare's public DNS resolver. Refer to the blog post for a deep dive. In short, Cloudflare generates two types of listings: image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/investigate/domain-ranking-datasets.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # Domains ranking Cloudflare regularly generates a domain ranking based on DNS queries to [1.1.1.1](https://developers.cloudflare.com/1.1.1.1/), Cloudflare's public DNS resolver. Refer to the [blog post ↗](https://blog.cloudflare.com/radar-domain-rankings/) for a deep dive. In short, Cloudflare generates two types of listings: * An ordered list of the top 100 most popular domains globally and per country. This includes the last 24 hours and is updated daily. * An unordered global most popular domains dataset, divided into buckets of the following number of domains: 200, 500, 1,000, 2,000, 5,000, 10,000, 20,000, 50,000, 100,000, 200,000, 500,000, 1,000,000\. It includes the last seven days and is updated weekly. ## List of endpoints ### Top #### Example: Get the current ordered top domains in the Cloudflare ranking Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/ranking/top?name=top&limit=5" \ --header "Authorization: Bearer " ``` ``` { "success": true, "errors": [], "result": { "top_0": [ { "rank": 1, "domain": "google.com" }, { "rank": 2, "domain": "googleapis.com" }, { "rank": 3, "domain": "facebook.com" }, { "rank": 4, "domain": "gstatic.com" }, { "rank": 5, "domain": "apple.com" } ] }, "meta": { // ... } } ``` For more information refer to [Get top domains](https://developers.cloudflare.com/api/resources/radar/subresources/ranking/methods/top/). #### Example: Download top `x` ranking bucket file As mentioned in the [blog post ↗](https://blog.cloudflare.com/radar-domain-rankings/), Cloudflare provides an ordered rank for the top 100 domains, but for the remainder it only provides ranking buckets — like top 200 thousand, top one million, etc.. These are available through Cloudflare's [datasets endpoints](https://developers.cloudflare.com/api/resources/radar/subresources/datasets/methods/list/). In the following example we will request the last available domain ranking buckets: Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/datasets?limit=10&datasetType=RANKING_BUCKET" \ --header "Authorization: Bearer " ``` ``` { "success": true, "errors": [], "result": { "datasets": [ { "id": 213, "title": "Top 1000000 ranking domains", "description": "Unordered top 1000000 from 2023-01-02 to 2023-01-09", "type": "RANKING_BUCKET", "tags": [ "GLOBAL", "top_1000000" ], "meta": { "top": 1000000 }, "alias": "ranking_top_1000000" }, // ... ] } } ``` If you are interested in a specific top (like the top one million), go through the `meta.top` property. After finding the top you are looking for, get its `id` to fetch the dataset using the [GET dataset download url](https://developers.cloudflare.com/api/resources/radar/subresources/datasets/methods/download/) endpoint. Then you can request a download url: Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/datasets/download" \ --header "Authorization: Bearer " \ --header "Content-Type: application/json" \ --data '{ "datasetId": 213 }' ``` ``` { "success": true, "errors": [], "result": { "dataset": { "url": "https://example.com/download" } } } ``` #### Example: Get the last top `x` ranking bucket This endpoint allows you to directly request the latest top x bucket available (optionally at a given date)[Get dataset stream](https://developers.cloudflare.com/api/resources/radar/subresources/datasets/methods/get/) endpoint. The dataset alias can be retrieved from the [Get datasets](https://developers.cloudflare.com/api/resources/radar/subresources/datasets/methods/list/) endpoint as the example above. This stream endpoint is only available for datasets generated after 2023-01-08. Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/datasets/ranking_top_1000" \ --header "Authorization: Bearer " ``` ``` domain 1rx.io 2mdn.net 360yield.com 3lift.com a-msedge.net a2z.com ... ``` ## Next steps Refer to [Investigate outages](https://developers.cloudflare.com/radar/investigate/outages/) to get data from outages occurring around the world. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/investigate/","name":"Investigate"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/investigate/domain-ranking-datasets/","name":"Domains ranking"}}]} ``` --- --- title: HTTP requests description: While in NetFlows we can inspect bytes and packets reaching Cloudflare's edge routers, in HTTP requests we are a layer above in the OSI model. HTTP requests examines complete HTTP requests from end users that reach websites served by Cloudflare's CDN. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/investigate/http-requests.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # HTTP requests While in [NetFlows](https://developers.cloudflare.com/radar/investigate/netflows/) we can inspect bytes and packets reaching Cloudflare's edge routers, in HTTP requests we are a layer above in the [OSI model ↗](https://en.wikipedia.org/wiki/OSI%5Fmodel). HTTP requests examines complete HTTP requests from end users that reach websites served by Cloudflare's [CDN ↗](https://www.cloudflare.com/en-gb/learning/cdn/what-is-a-cdn/). Note HTTP traffic includes both HTTP and HTTPS traffic coming from end users. Most of the charts in the [Adoption and Usage ↗](https://radar.cloudflare.com/adoption-and-usage) section on Radar come from this data source. These endpoints can be broadly split into: * `timeseries`: A time series of a group of metrics. For example, when looking at IP version, displays an IPv4 time series and an IPv6 time series. * `summary`: Displays a summary of a group of metrics over the specified time range. For example, IPv4 traffic percentage out of the total HTTP traffic during that time period. * `top`: A list of the top locations or [Autonomous Systems ↗](https://www.cloudflare.com/en-gb/learning/network-layer/what-is-an-autonomous-system/) (ASes) ranked by adoption of a specific metric. For example, top locations by mobile device traffic (like which locations have a higher percentage of mobile traffic out of the total traffic for that location). ## List of endpoints ### Timeseries #### Example: hourly breakdown by device type In this example, we will request traffic by device type globally, with and without [bot traffic](https://developers.cloudflare.com/radar/concepts/bot-classes/). Parameters for the `human` series are `name=human&botClass=LIKELY_HUMAN&dateRange=1d`. For the `bot` series, the parameters are `name=bot&botClass=LIKELY_AUTOMATED&dateRange=1d`: Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/http/timeseries/device_type?name=human&botClass=LIKELY_HUMAN&dateRange=1d&name=bot&botClass=LIKELY_AUTOMATED&dateRange=1d&format=json&aggInterval=1h" \ --header "Authorization: Bearer " ``` Here is the abbreviated response: ``` { "success": true, "errors": [], "result": { "human": { "timestamps": ["2022-11-03T13:00:00Z", "2022-11-03T14:00:00Z", ".."], "mobile": ["52.5532", "52.146628", ".."], "desktop": ["47.394791", "47.800731", ".."], "other": ["0.052009", "0.052642", ".."] }, "bot": { "timestamps": ["2022-11-03T13:00:00Z", "2022-11-03T14:00:00Z", ".."], "desktop": ["83.833892", "84.017711", ".."], "mobile": ["16.156748", "15.969936", ".."], "other": ["0.00936", "0.012353", ".."] }, "meta": { "dateRange": { "startTime": "2022-11-03T13:00:00Z", "endTime": "2022-11-04T13:00:00Z" }, "normalization": "PERCENTAGE" } } } ``` Mobile devices tend to be considerably more present when examining human generated traffic versus bot generated traffic. Note Note that device classification comes from the [User-agent ↗](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/User-Agent) header. Ultimately, this classification depends on the user agent(s) that bots use. For more information refer to [Get device types time series](https://developers.cloudflare.com/api/resources/radar/subresources/http/subresources/timeseries%5Fgroups/methods/device%5Ftype/). ### Summary #### Example: overall breakdown by device type and human/bot traffic We can also look at the same information asking for a summary of the device type breakdown over the entire period, instead of a per hour breakdown like in the example before. Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/http/summary/device_type?name=human&botClass=LIKELY_HUMAN&dateRange=1d&name=bot&botClass=LIKELY_AUTOMATED&dateRange=1d&format=json&aggInterval=1h" \ --header "Authorization: Bearer " ``` Here is the abbreviated response: ``` { "success": true, "errors": [], "result": { "human": { "mobile": "54.967243", "desktop": "44.974006", "other": "0.058751" }, "bot": { "desktop": "83.275452", "mobile": "16.707455", "other": "0.017093" } } } ``` For more information refer to the [API reference](https://developers.cloudflare.com/api/resources/radar/subresources/http/subresources/summary/methods/device%5Ftype/) for this endpoint. #### Example: breakdown by IP version and human/bot traffic In the following example, we will examine global breakdown of traffic by IP version, with and without bots: Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/http/summary/ip_version?name=human&botClass=LIKELY_HUMAN&dateRange=1d&name=bot&botClass=LIKELY_AUTOMATED&dateRange=1d&format=json&aggInterval=1h" \ --header "Authorization: Bearer " ``` This returns the following: ``` { "success": true, "errors": [], "result": { "human": { "IPv4": "76.213647", "IPv6": "23.786353" }, "bot": { "IPv4": "91.492032", "IPv6": "8.507968" } } } ``` Bots tend to use more IPv4 addresses. It is also interesting to know how your ISP fares in IPv6 adoption. If you know your ISP’s autonomous system number (ASN), you can use the `asn` parameter to query for this information. Refer to the [API reference](https://developers.cloudflare.com/api/resources/radar/subresources/http/subresources/summary/methods/ip%5Fversion/) for other parameters. If you do not know your ISP’s ASN, you can use [Radar ↗](https://radar.cloudflare.com/ip) to find what it is. ### Top #### Example: top locations by IPv6 traffic In the following example, we will find which locations had a higher adoption of [IPv6 ↗](https://en.wikipedia.org/wiki/IPv6) in the last 28 days. Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/http/top/locations/ip_version/IPv6?name=ipv6&botClass=LIKELY_HUMAN&dateRange=28d&format=json&limit=5" \ --header "Authorization: Bearer " ``` ``` { "success": true, "errors": [], "result": { "ipv6": [ { "clientCountryAlpha2": "IN", "clientCountryName": "India", "value": "50.612747" }, { "clientCountryAlpha2": "MY", "clientCountryName": "Malaysia", "value": "46.233654" }, { "clientCountryAlpha2": "UY", "clientCountryName": "Uruguay", "value": "39.796762" }, { "clientCountryAlpha2": "LK", "clientCountryName": "Sri Lanka", "value": "39.709355" }, { "clientCountryAlpha2": "VN", "clientCountryName": "Vietnam", "value": "39.1514" } ] } } ``` According to the returned data, India is leading in IPv6 adoption. For more information refer to the [API reference](https://developers.cloudflare.com/api/resources/radar/subresources/http/subresources/locations/subresources/ip%5Fversion/methods/get/) for this endpoint. ## Next steps Refer to [Application layer attacks](https://developers.cloudflare.com/radar/investigate/application-layer-attacks/) to learn more about mitigfated HTTP requests. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/investigate/","name":"Investigate"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/investigate/http-requests/","name":"HTTP requests"}}]} ``` --- --- title: NetFlows description: NetFlows shows network traffic data from end users collected from Cloudflare's edge routers. NetFlows' data also feeds the Internet traffic change chart. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/investigate/netflows.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # NetFlows [NetFlows ↗](https://en.wikipedia.org/wiki/NetFlow) shows network traffic data from end users collected from Cloudflare's edge routers. NetFlows' data also feeds the [Internet traffic change ↗](https://radar.cloudflare.com/) chart. NetFlows includes all types of traffic from Cloudflare's routers, not just traffic to websites served by Cloudflare's [CDN ↗](https://www.cloudflare.com/en-gb/learning/cdn/what-is-a-cdn/). ## List of endpoints ### Timeseries #### Example: filtering by product Besides comparing time series across locations or date ranges (discussed in [Make comparisons](https://developers.cloudflare.com/radar/get-started/making-comparisons/)), we can also examine `ALL` traffic versus only `HTTP` traffic using the `product` filter. For more information, refer to the [API reference](https://developers.cloudflare.com/api/resources/radar/subresources/netflows/methods/timeseries/) for this endpoint. NetFlow products `HTTP` traffic only includes web traffic to Cloudflare's zones, while `ALL` also includes traffic to all other services, like [Spectrum](https://developers.cloudflare.com/spectrum/), [Magic Transit](https://developers.cloudflare.com/magic-transit/), [1.1.1.1](https://developers.cloudflare.com/1.1.1.1/), and others. In the following example, we will examine both `ALL` and `HTTP` traffic in two [autonomous systems ↗](https://www.cloudflare.com/en-gb/learning/network-layer/what-is-an-autonomous-system/). First, we will examine [AS3243 ↗](https://radar.cloudflare.com/as3243), a Portuguese local Internet Service Provider (ISP). The parameters for all traffic are `name=AS3243_all&product=ALL&dateRange=1d&asn=3243`, and for just the HTTP traffic are `name=AS3243_http&product=HTTP&dateRange=1d&asn=3243`): Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/netflows/timeseries?name=meo_all&product=ALL&dateRange=1d&asn=3243&name=meo_http&product=HTTP&dateRange=1d&asn=3243&format=json&aggInterval=1h" \ --header "Authorization: Bearer " ``` This is the abbreviated response: ``` { "success": true, "errors": [], "result": { "AS3243_all": { "timestamps": ["2022-11-08T14:00:00Z", "2022-11-08T15:00:00Z", "..."], "values": ["0.565885", "0.586434", "..."] }, "AS3243_http": { "timestamps": ["2022-11-08T14:00:00Z", "2022-11-08T15:00:00Z", "..."], "values": ["0.548564", "0.568329", "..."] } } } ``` `HTTP` traffic values are similar to `ALL` traffic values. This means that most traffic Cloudflare receives from this AS is traffic to websites served by Cloudflare's [CDN ↗](https://www.cloudflare.com/en-gb/learning/cdn/what-is-a-cdn/) product. In this other example, we will examine [AS174 ↗](https://radar.cloudflare.com/as174), another autonomous system that is not an ISP: Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/netflows/timeseries?name=AS174_all&product=ALL&dateRange=1d&asn=174&name=AS174_http&product=HTTP&dateRange=1d&asn=174&format=json&aggInterval=1h" \ --header "Authorization: Bearer " ``` The abbreviated response is: ``` { "success": true, "errors": [], "result": { "AS174_all": { "timestamps": ["2022-11-08T14:00:00Z", "2022-11-08T15:00:00Z", "..."], "values": ["0.917348", "1.0", "..."] }, "AS174_http": { "timestamps": ["2022-11-08T14:00:00Z", "2022-11-08T15:00:00Z", "..."], "values": ["0.381777", "0.408091", "..."] } } } ``` Here, there is less `HTTP` traffic compared to other types of traffic — which makes sense, since this is not an ISP serving end-users. Note that here we made two separate requests since we are only interested in whether `HTTP` comprises the majority of the traffic in each AS or not. If we wanted to actually [compare](https://developers.cloudflare.com/radar/get-started/making-comparisons/) the traffic values between them to, for example, examine who has more traffic, we would have to make a single request including all series. Here is how we could do that: Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/netflows/timeseries?name=AS174_all&product=ALL&dateRange=1d&asn=174&name=AS174_http&product=HTTP&dateRange=1d&asn=174&name=AS3243_all&product=ALL&dateRange=1d&asn=3243&name=AS3243_http&product=HTTP&dateRange=1d&asn=3243&format=json&aggInterval=1h" \ --header "Authorization: Bearer " ``` which would lead to a response like this: ``` { "success": true, "errors": [], "result": { "AS174_all": { "timestamps": ["2022-11-08T14:00:00Z", "2022-11-08T15:00:00Z", "..."], "values": ["0.917348", "1.0", "..."] }, "AS174_http": { "timestamps": ["2022-11-08T14:00:00Z", "2022-11-08T15:00:00Z", "..."], "values": ["0.381777", "0.408091", "..."] }, "AS3243_all": { "timestamps": ["2022-11-08T14:00:00Z", "2022-11-08T15:00:00Z", "..."], "values": ["0.317136", "0.328652", "..."] }, "AS3243_http": { "timestamps": ["2022-11-08T14:00:00Z", "2022-11-08T15:00:00Z", "..."], "values": ["0.307429", "0.318505", "..."] } } } ``` This response shows how Cloudflare receives more traffic from AS174 than from AS3243. ## Next steps Refer to [HTTP requests](https://developers.cloudflare.com/radar/investigate/http-requests/) for more information about requests from end users. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/investigate/","name":"Investigate"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/investigate/netflows/","name":"NetFlows"}}]} ``` --- --- title: Network layer attacks description: Network layer attacks show DDoS attack trends at the network layer. These attacks can be split by the network protocol they use: ICMP, TCP, UDP and others. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/investigate/network-layer-attacks.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # Network layer attacks Network layer attacks show [DDoS ↗](https://www.cloudflare.com/en-gb/learning/ddos/layer-3-ddos-attacks/) attack trends at the network layer. These attacks can be split by the network protocol they use: [ICMP ↗](https://www.cloudflare.com/en-gb/learning/ddos/glossary/internet-control-message-protocol-icmp/), [TCP ↗](https://www.cloudflare.com/learning/ddos/glossary/tcp-ip/), [UDP ↗](https://www.cloudflare.com/en-gb/learning/ddos/glossary/user-datagram-protocol-udp/) and others. Note Unlike what happens in [Application Layer Attacks](https://developers.cloudflare.com/radar/investigate/application-layer-attacks/), in network layer attacks location attribution does not use the location associated with the client's IP address. Instead, it uses the location of the data center itself. This is due to [IP spoofing ↗](https://www.cloudflare.com/en-gb/learning/ddos/glossary/ip-spoofing/). When filtering by location or autonomous system (AS), we are filtering by the source location/AS of the attack — which can be very different to the location of the human orchestrator of the attack. Refer to [botnets ↗](https://www.cloudflare.com/learning/ddos/what-is-a-ddos-botnet/) for more information. ## List of endpoints ### Timeseries #### Example: hourly percentage breakdown by attack method In the following example, we will examine the worldwide versus Singapore distribution of mitigated attacks by network protocol: Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/attacks/layer3/timeseries_groups?name=global&dateRange=1d&location=&name=singapore&location=SG&dateRange=1d&aggInterval=1h&format=json" \ --header "Authorization: Bearer " ``` If we inspect the abbreviated response below, we can conclude that globally, at those timestamps, `UDP` and `TCP` attacks were mostly evenly split. ``` { "success": true, "errors": [], "result": { "global": { "timestamps": ["2022-11-06T13:00:00Z", "2022-11-06T14:00:00Z", "..."], "udp": ["50.784034", "51.055221", "..."], "tcp": ["49.213944", "48.943769", "..."], "icmp": ["0.002023", "0.001009", "..."], "gre": ["0.0", "0.0", "0.0", "..."] }, "singapore": { "timestamps": ["2022-11-06T13:00:00Z", "2022-11-06T14:00:00Z", "..."], "tcp": ["79.605287", "83.943885", "..."], "udp": ["20.394594", "16.056115", "..."], "icmp": ["0.000119", "0.0", "..."], "gre": ["0.0", "0.0", "..."] }, "meta": { "dateRange": { "startTime": "2022-11-06T13:00:00Z", "endTime": "2022-11-07T13:00:00Z" }, "normalization": "PERCENTAGE", // ... } } } ``` We can also conclude that the distribution of network layer attacks coming from Singapore — or, more accurately, reaching Cloudflare's data center located in Singapore — differs quite a bit from the worldwide distribution. At those times, the distribution of network layer attacks clearly favors [TCP ↗](https://www.cloudflare.com/learning/ddos/glossary/tcp-ip/). For more information refer to the [API reference](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer3/methods/timeseries/) for this endpoint. ### Summary #### Example: Russia - overall percentage breakdown by network protocol We can also filter by source location and examine attacks coming from Russia: Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/attacks/layer3/summary?location=RU&name=attacks_ru&dateRange=1d&format=json" \ --header "Authorization: Bearer " ``` ``` { "success": true, "errors": [], "result": { "attacks_ru": { "udp": "86.682356", "tcp": "11.928664", "gre": "1.381015", "icmp": "0.007965" }, "meta": { "dateRange": { "startTime": "2022-11-06T15:00:00Z", "endTime": "2022-11-07T15:00:00Z" }, "normalization": "PERCENTAGE", // ... } } } ``` The response shows that the attacks coming from Russia to other locations tended to use the [UDP ↗](https://www.cloudflare.com/en-gb/learning/ddos/glossary/user-datagram-protocol-udp/) network protocol at those timestamps. For more information refer to the [API reference](https://developers.cloudflare.com/api/resources/radar/subresources/attacks/subresources/layer3/methods/timeseries/) for this endpoint. ## Next steps Refer to [DNS](https://developers.cloudflare.com/radar/investigate/dns/) to learn more about the aggregated and anonymized DNS queries to Cloudflare's [1.1.1.1](https://developers.cloudflare.com/1.1.1.1/) public resolver service. ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/investigate/","name":"Investigate"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/investigate/network-layer-attacks/","name":"Network layer attacks"}}]} ``` --- --- title: Outages description: Cloudflare Radar Outage Center (CROC) provides data on outages occurring around the world. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/investigate/outages.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # Outages [Cloudflare Radar Outage Center (CROC) ↗](https://radar.cloudflare.com/outage-center) provides data on outages occurring around the world. Refer the [blog post ↗](https://blog.cloudflare.com/announcing-cloudflare-radar-outage-center/) for more information but, in short, Radar provides the following information: * **Location**: Where was the outage? * **ASN**: What autonomous system experienced a disruption in connectivity? * **Type**: How broad was the outage? Did connectivity fail nationwide, or at a sub-national level? Did just a single network provider have an outage? * **Scope**: If it was a sub-national/regional outage, what state or city was impacted? If it was a network-level outage, which one was it? * **Cause**: Insight into the likely cause of the outage, based on publicly available information. Historically, some outages have been government directed shutdowns, while others are caused by severe weather or natural disasters, or by infrastructure issues such as cable cuts, power outages, or filtering/blocking. * **Start time**: When did the outage start? * **End time**: When did the outage end? ## List of endpoints ### Outages #### Example: Get outages in the last 7 days Terminal window ``` curl "https://api.cloudflare.com/client/v4/radar/annotations/outages?limit=5&offset=0&dateRange=7d&format=json" \ --header "Authorization: Bearer " ``` ``` { "success": true, "errors": [], "result": { "annotations": [ { "dataSource": "ALL", "description": null, "scope": "Multiple regions/cities", "startDate": "2022-10-25T00:00:00Z", "endDate": null, "locations": ["UA"], "asns": [], "eventType": "OUTAGE", "linkedUrl": "https://www.npr.org/2022/10/22/1130742768/ukraine-power-grid-outages-record-damage", "outage": { "outageCause": "POWER_OUTAGE", "outageType": "REGIONAL" } }, { "dataSource": "ALL", "description": null, "scope": "Multiple cities in Florida", "startDate": "2022-09-28T19:00:00Z", "endDate": "2022-11-02T00:00:00Z", "locations": ["US"], "asns": [], "eventType": "OUTAGE", "linkedUrl": "https://x.com/CloudflareRadar/status/1575229448353349632", "outage": { "outageCause": "WEATHER", "outageType": "REGIONAL" } } ] } } ``` Refer to the [API reference](https://developers.cloudflare.com/api/resources/radar/subresources/annotations/subresources/outages/methods/get/) for more information regarding this endpoint. Having data on a given outage allows you to examine its impact through both [NetFlows](https://developers.cloudflare.com/radar/investigate/netflows/) (like in the [Tonga outage](https://developers.cloudflare.com/radar/get-started/making-comparisons/#use-specific-timestamps) and [others ↗](https://blog.cloudflare.com/q3-2022-internet-disruption-summary/)) and [HTTP](https://developers.cloudflare.com/radar/investigate/http-requests/) data (for example, did the outage affect more mobile than desktop traffic?). ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/investigate/","name":"Investigate"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/investigate/outages/","name":"Outages"}}]} ``` --- --- title: URL Scanner description: To better understand Internet usage around the world, use Cloudflare's URL Scanner. With Cloudflare's URL Scanner, you have the ability to investigate the details of a domain, IP, URL, or ASN. Cloudflare's URL Scanner is available in the Security Center of the Cloudflare dashboard, Cloudflare Radar, and the Cloudflare API. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/investigate/url-scanner.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # URL Scanner To better understand Internet usage around the world, use Cloudflare's URL Scanner. With Cloudflare's URL Scanner, you have the ability to investigate the details of a domain, IP, URL, or ASN. Cloudflare's URL Scanner is available in the Security Center of the Cloudflare dashboard, [Cloudflare Radar ↗](https://radar.cloudflare.com/scan), and the Cloudflare [API](https://developers.cloudflare.com/api/resources/url%5Fscanner/). ## Use the API To make your first URL scan using the API, you must obtain a URL Scanner specific [API token](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/). Create a Custom Token with _Account_ \> _URL Scanner_ in the **Permissions** group, and select _Edit_ as the access level. Once you have the token, and you know your `account_id`, you are ready to make your first request to the API at `https://api.cloudflare.com/client/v4/accounts/{account_id}/urlscanner/`. ### Submit URL to scan To submit a URL to scan, the only required information is the URL to be scanned in the `POST` request body: Terminal window ``` curl "https://api.cloudflare.com/client/v4/accounts/{account_id}/urlscanner/v2/scan" \ --header "Authorization: Bearer " \ --header "Content-Type: application/json" \ --data '{ "url": "https://www.example.com" }' ``` By default, the report will have a `Public` visibility level, which means it will appear in the [recent scans ↗](https://radar.cloudflare.com/scan#recent-scans) list and in search results. It will also include a single screenshot with desktop resolution. A successful response will have a status code of `200` and be similar to the following: ``` { "uuid": "095be615-a8ad-4c33-8e9c-c7612fbf6c9f", "api": "https://api.cloudflare.com/client/v4/accounts//urlscanner/v2/result/095be615-a8ad-4c33-8e9c-c7612fbf6c9f", "visibility": "public", "url": "https://www.example.com", "message": "Submission successful" } ``` You can submit up to 100 URLs at the same time via the [API ↗](https://developers.cloudflare.com/api/resources/url%5Fscanner/subresources/scans/methods/bulk%5Fcreate/). The `uuid` property in the response above identifies the scan and will be required when fetching the scan report. #### Submit a custom URL Scan Here's an example request body with some custom configuration options: ``` { "url": "https://example.com", "screenshotsResolutions": [ "desktop", "mobile", "tablet" ], "customagent": "XXX-my-user-agent", "referer": "example", "customHeaders": { "Authorization": "xxx-token" }, "visibility": "Unlisted" } ``` Above, the visibility level is set as `Unlisted`, which means that the scan report won't be included in the [recent scans ↗](https://radar.cloudflare.com/scan#recent-scans) list nor in search results. In effect, only users with knowledge of the scan ID will be able to access it. There will also be three screenshots taken of the webpage, one per target device type. The [User-Agent ↗](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/User-Agent) will be set as "XXX-my-user-agent". Note that you can set any custom HTTP header, including [Authorization ↗](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Authorization). Header Successful scans are subject to a retention policy of 12 months. Failed scans older than 30 days will be deleted. ### Get scan report Once the URL Scan submission is made, the current progress can be checked by calling `https://api.cloudflare.com/client/v4/accounts/{account_id}/urlscanner/v2/result/{scan_id}`. The `scan_id` will be the `uuid` value returned in the previous response. While the scan is in progress, the HTTP status code will be `404`; once it is finished, it will be `200`. Cloudflare recommends that you poll every 10-30 seconds. The response will include, among others, the following top properties: * `task` \- Information on the scan submission. * `page` \- Information pertaining to the primary response, for example IP address, ASN, server, and page redirect history. * `data.requests` \- Request chains involved in the page load. * `data.cookies` \- Cookies set by the page. * `data.globals` \- Non-standard JavaScript global variables. * `data.console` \- Console logs. * `data.performance` \- Timings as given by the [PerformanceNavigationTiming ↗](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceNavigationTiming) interface. * `meta` \- Meta processors output including detected technologies, domain and URL categories, rank, geolocation information, and others. * `lists.ips` \- IPs contacted. * `lists.asns` \- AS Numbers contacted. * `lists.domains` \- Hostnames contacted, including `dns` record information. * `lists.hashes` \- Hashes of response bodies, of the main page HTML structure, screenshots, and favicons. * `lists.certificates` \- TLS certificates of HTTP responses. * `verdicts` \- Verdicts on malicious content. Some examples of more specific properties include: * `task.uuid` \- ID of the scan. * `task.url` \- Submitted URL of the scan. May differ from final URL (`page.url`) if there are HTTP redirects. * `task.success` \- Whether scan was successful or not. Scans can fail for various reasons, including DNS errors. * `task.status` \- Current scan status, for example, `Queued`, `InProgress`, or `Finished`. * `meta.processors.domainCategories` \- Cloudflare categories of the main hostname contacted. * `meta.processors.phishing` \- What kind of phishing, if any, was detected. * `meta.processors.radarRank` \- [Cloudflare Radar Rank ↗](http://blog.cloudflare.com/radar-domain-rankings/) of the main hostname contacted. * `meta.processors.wappa` \- The kind of technologies detected as being in use by the website, with the help of [Wappalyzer ↗](https://github.com/Lissy93/wapalyzer). * `page.url` \- URL of the primary request, after all HTTP redirects. * `page.country` \- Country name from geolocation data associated with the main IP address contacted. * `page.history` \- Main page history, including any HTTP redirects. * `page.screenshot` \- Various hashes of the main screenshot. Can be used to search for sites with similar screenshots. * `page.domStructHash` \- HTML structure hash. Use it to search for sites with similar structure. * `page.favicon.hash` \- MD5 hash of the favicon. * `verdicts.overall.malicious` \- Whether the website was considered malicious _at the time of the scan_. Please check the remaining properties for each subsystem(s) for specific threats detected. The [Get URL Scan](https://developers.cloudflare.com/api/resources/url%5Fscanner/subresources/scans/methods/get/) API endpoint documentation contains the full response schema. To fetch the scan's [screenshots](https://developers.cloudflare.com/api/resources/url%5Fscanner/subresources/scans/methods/screenshot/) or full [network log](https://developers.cloudflare.com/api/resources/url%5Fscanner/subresources/scans/methods/har/) refer to the corresponding endpoints' documentation. ### Search scans Use a subset of ElasticSearch Query syntax to filter scans. Search results will include `Public` scans and your own `Unlisted` scans. To search for scans to the hostname `google.com`, use the query parameter `q=page.domain:"google.com"`: Terminal window ``` curl 'https://api.cloudflare.com/client/v4/accounts/{account_id}/urlscanner/v2/search?q=page.domain:google.com' \ --header "Authorization: Bearer " ``` If, instead, you wanted to search for scans that made at least one request to the hostname `cdnjs.cloudflare.com`, for example sites that use a JavaScript library hosted at `cdnjs.cloudflare.com`, use the query parameter `hostname=cdnjs.cloudflare.com`: Terminal window ``` curl "https://api.cloudflare.com/client/v4/accounts/{account_id}/urlscanner/v2/search?q=domain:cdnjs.cloudflare.com" \ --header "Authorization: Bearer " ``` Some other example queries: * `task.url:"https://google.com" OR task.url:"https://www.google.com"`: Search for scans whose submitted URL was either `google.com` or `www.google.com`. URLs must be enclosed in quotes. * `page.url:"https://google.com" AND NOT task.url:"https://google.com"`: Search for scans to `google.com` whose submitted URL was not `google.com` (that is, sites that redirected to google.com). * `page.domain:microsoft AND verdicts.malicious:true AND NOT page.domain:microsoft.com`: Malicious scans whose hostname starts with `microsoft`. Would match domains like `microsoft.phish.com`. * `apikey:me AND date:[2024-01 TO 2024-10]`: Your scans from January 2024 to October 2024. * `page.domain:(blogspot OR www.blogspot)`: Searches for scans whose main domain starts with `blogspot` or with `www.blogspot`. * `date:>now-7d AND path:okta-sign-in.min.js`: Scans from the last seven days with any request path that ends with `okta-sign-in.min.js`. * `page.asn:AS24940 AND hash:-557369673`: Websites hosted in AS24940 where a resource with the given hash was retrieved. * `hash:8f662c2ce9472ba8d03bfeb8cdae112dbc0426f99da01c5d70c7eb4afd5893ca`: Using the hash at `page.domStructHash` search for other scans with the same HTML structure hash. Go to [Search URL scans](https://developers.cloudflare.com/api/resources/url%5Fscanner/subresources/scans/methods/list/) in the API documentation for the full list of available options. ### Security Center Alternatively, you can search in the Security Center: 1. In the Cloudflare dashboard, go to the **Investigate** page. [ Go to **Investigate** ](https://dash.cloudflare.com/?to=/:account/security-center/investigate) 2. Enter your query and select **Search**. You can scan a URL by location. Scanning a URL by location allows you to analyze how a website may present different content depending on your location. This helps to expose and examine region-specific malicious activities. Note Only Enterprise customers can scan a URL by location. To scan a URL based on your geographic location: 1. Enter your URL. 2. Go to **Location** \> Select which country to scan the URL from. 3. Select **Scan now**. You can also use the [API ↗](https://developers.cloudflare.com/api/resources/url%5Fscanner/subresources/scans/methods/create/#%28params%29%20default%20%3E%20%28param%29%20account%5Fid%20%3E%20) to scan a URL from a specific location. In Security Center, you can retrieve pre-filtered information by: * Similar screenshot * Identical favicon * Similar favicon * Similar HTML structure * Identical ASN * Identical IP * Identical domain * Identical final URL (after all redirections) ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/investigate/","name":"Investigate"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/investigate/url-scanner/","name":"URL Scanner"}}]} ``` --- --- title: Quarterly DDoS threat reports description: Quarterly DDoS threat reports provide a comprehensive overview of DDoS attack insights and trends over a three-month period. image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) Was this helpful? YesNo [ Edit page ](https://github.com/cloudflare/cloudflare-docs/edit/production/src/content/docs/radar/reference/quarterly-ddos-reports.mdx) [ Report issue ](https://github.com/cloudflare/cloudflare-docs/issues/new/choose) Copy page # Quarterly DDoS threat reports Quarterly DDoS threat reports provide a comprehensive overview of DDoS attack insights and trends over a three-month period. Thanks to our vast network, Cloudflare provides insights on the evolving threat landscape, including variations in attack sizes, techniques, top source countries, top targeted countries and targeted industries. Each report presents a global outlook, dives into significant attacks and campaigns, and explores shifts in DDoS tactics, offering a blend of data analysis and insights to better understand the cyber threat environment. Find the latest quarterly DDoS threat reports in the [**Reports** ↗](https://radar.cloudflare.com/reports) section of Cloudflare Radar. --- ## Methodologies ### How we count the number of DDoS attacks Cloudflare's main DDoS system, the [DDoS Managed Ruleset](https://developers.cloudflare.com/ddos-protection/managed-rulesets/), generates real-time fingerprints for DDoS attacks that it automatically detects and mitigates. While there may be multiple fingerprints generated for a single DDoS attack, or attack campaign, we count unique fingerprints that resulted in mitigation to get an understanding of the number of DDoS attacks for a given period of time. While in some cases, we can see an 'explosion' of fingerprints due to randomized DDoS attacks, for the most part, this figure gives us a reliable indicator to track over time. Currently, the number of DDoS attacks does not take into consideration the [Advanced TCP Protection system](https://developers.cloudflare.com/ddos-protection/advanced-ddos-systems/overview/advanced-tcp-protection/) or the [Advanced DNS Protection system](https://developers.cloudflare.com/ddos-protection/advanced-ddos-systems/overview/advanced-dns-protection/). We also don't take into account any mitigations by customer-created rules or configuration. ### How we calculate ransom DDoS attack insights Cloudflare’s systems constantly analyze traffic and automatically apply mitigation when DDoS attacks are detected. Each attacked customer is prompted with an automated survey to help Cloudflare better understand the nature of the attack and the success of the mitigation. For over two years, Cloudflare has been surveying attacked customers. One of the questions in the survey asks the respondents if they received a threat or a ransom note. Over the past few years, on average, Cloudflare has been collecting around 200 responses per quarter. The responses of this survey are used to calculate the percentage of ransom DDoS attacks. ### How we calculate geographical and industry insights #### Source country At the application layer, Cloudflare uses the attacking IP addresses to understand the origin country of the attacks. That is because at that layer, IP addresses cannot be spoofed [1](#user-content-fn-1) (or modified). However, at the network layer, source IP addresses can be spoofed. So, instead of relying on IP addresses to understand the source, Cloudflare uses the location of our data centers where the attack packets were ingested. It is possible to obtain geographical accuracy due to Cloudflare's large global coverage in over 300 locations around the world. #### Target country For both application-layer and network-layer DDoS attacks, attacks and traffic are grouped by customers’ billing country. This allows Cloudflare to understand which countries are subject to more attacks. #### Target industry For both application-layer and network-layer DDoS attacks, attacks and traffic are grouped by customers’ industry according to the internal customer relations management system. This allows Cloudflare to understand which industries are subject to more attacks. #### Total volume versus percentage For both source and target insights, Cloudflare looks at the total volume of attack traffic compared to all traffic as one data point. Additionally, Cloudflare also takes into account the percentage of attack traffic towards or from a specific country, to a specific country or to a specific industry. This gives us an "attack activity rate" for a given country/industry which is normalized by their total traffic levels. This helps us remove biases of a country or industry that normally receives a lot of traffic and therefore, a lot of attack traffic as well. #### Ranking For source, target, and industry insights, Cloudflare may calculate a "Rank" for each dimension. The calculation takes into consideration HTTP DDoS attacks, network-layer DDoS attacks, and the total volume and the percentage of DDoS attack traffic out of the total traffic for each attack type. The Ranking system lets Cloudflare provide a simple single score that means how much a certain industry is being attacked, for example. In the graphs, the Rank values are displayed in an inverted way (a longer bar in the chart means a higher rank and more attacks). ### How we calculate attack characteristics To calculate the attack size, duration, attack vectors, and emerging threats, Cloudflare buckets attacks and then provides the share of each bucket out of the total amount for each dimension. However, in the **Network layer attack distribution** graph of the [**Security & Attacks** ↗](https://radar.cloudflare.com/security-and-attacks) Radar page these trends are calculated by number of bytes instead. Since attacks may vary greatly in number of bytes from one another, this could lead to trends differing between the quarterly reports and the graph displayed in Cloudflare Radar. --- ## Final remarks ### Countries as source or target of attacks When Cloudflare describes "top countries" as the source or target of attacks, it does not necessarily mean that a certain country was attacked as a country, but rather that organizations that use that country as their billing country were targeted by attacks. Similarly, "attacks originating from a country" does not mean that a given country launched the attacks, but rather that the attack was launched from IP addresses mapped to that country. Threat actors operate global botnets with nodes all over the world, and often also use VPNs (virtual private networks) and proxies to obfuscate their true location. This means that the source country could indicate the presence of exit nodes or botnet nodes within that country. ### Excluded items due to insufficient data The insights and trends presented in quarterly reports exclude certain countries and industries when there is not enough data to provide statistically meaningful insights. ### Map chart coloring In the map charts, the countries and regions are colored using a diverging scale, ranging from white (minimum value) to red (maximum value). These vary according to the selected world continent group. ## Footnotes 1. IP spoofing is the creation of Internet Protocol (IP) packets which have a modified source address to hide the identity of the sender, impersonate another computer system, or both. [↩](#user-content-fnref-1) ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/radar/","name":"Radar"}},{"@type":"ListItem","position":3,"item":{"@id":"/radar/reference/","name":"Reference"}},{"@type":"ListItem","position":4,"item":{"@id":"/radar/reference/quarterly-ddos-reports/","name":"Quarterly DDoS threat reports"}}]} ```