On Monday, September 30, customers on Verizon’s mobile network in multiple cities across the United States reported experiencing a loss of connectivity. Impacted phones showed “SOS” instead of the usual bar-based signal strength indicator, and customers complained of an inability to make or receive calls on their mobile devices.
AS6167 (CELLCO) is the autonomous system used by Verizon for its mobile network. To better understand how the outage impacted Internet traffic on Verizon’s network, we took a look at HTTP request volume from AS6167 independent of geography, as well as traffic from AS6167 in various cities that were reported to be the most significantly impacted.
Although initial reports of connectivity problems started around 09:00 ET (13:00 UTC), we didn’t see a noticeable change in request volume at an ASN level until about two hours later. Just before 12:00 ET (16:00 UTC), Verizon published a social media post acknowledging the problem, stating “We are aware of an issue impacting service for some customers. Our engineers are engaged and we are working quickly to identify and solve the issue.”
As the Cloudflare Radar graph below shows, a slight decline (-5%) in HTTP traffic as compared to traffic at the same time a week prior is first visible around 11:00 ET (15:00 UTC). Request volume fell as much as 9% below expected levels at 13:45 ET (17:45 UTC).
Just after 17:00 ET (21:00 UTC), Verizon published a second social media post noting, in part, “Verizon engineers are making progress on our network issue and service has started to be restored.” Request volumes returned to expected levels around the same time, surpassing the previous week’s levels at 17:15 ET (21:15 UTC). At 19:18 ET (23:18 UTC), a social media post from Verizon noted “Verizon engineers have fully restored today’s network disruption that impacted some customers. Service has returned to normal levels.”
Media reports listed cities including Chicago, Indianapolis, New York City, Atlanta, Cincinnati, Omaha, Phoenix, Denver, Minneapolis, Seattle, Los Angeles, and Las Vegas as being most impacted. In addition to looking at comparative traffic trends across the whole Verizon Wireless network, we also compared request volumes in the listed cities to the same time a week prior (September 23).
Declines in request traffic starting around 11:00 ET (15:00 UTC) are clearly visible in cities including Los Angeles, Seattle, Omaha, Denver, Phoenix, Minneapolis, Indianapolis, and Chicago. In contrast to other cities, Omaha’s request volume was already trending lower than last week heading into today’s outage, but its graph clearly shows the impact of today’s disruption as well. Omaha’s difference in traffic was the most significant, down approximately 30%, while other cities saw declines in the 10-20% range.
Request traffic from Las Vegas initially appeared to exhibit a bit of volatility around 11:00 ET (15:00 UTC), but continues to track fairly closely to last week’s levels before exceeding them starting at 16:00 ET (20:00 UTC). Cincinnati was tracking slightly above last week’s request volume before the outage began, and tracked closely to the prior week during the outage period.
We observed week-over-week traffic increases during the outage period in New York and Atlanta. However, in both cities, traffic was already slightly above last week’s levels, and that trend continued throughout the day.
Based on our observations, it appears that voice services on Verizon’s network may have been more significantly impacted than data services, as we saw some declines in request traffic across impacted cities, but none experienced full outages.
As of this writing (19:15 ET, 23:15 UTC), no specific information has been made available by Verizon regarding the root cause of the network problems.
Cloudflare Radar showcases global Internet traffic patterns, attack activity, 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, and is built on top of a rich, publicly accessible API. This API allows users to explore Radar data beyond the default set of visualizations, for example filtering by protocol, comparing metrics across multiple locations or autonomous systems, or examining trends over two different periods of time. However, not every user has the technical know-how to make a raw API query or process the JSON-formatted response.
Today, we are launching the Cloudflare Radar Data Explorer, which provides a simple Web-based interface to enable users to easily build more complex API queries, including comparisons and filters, and visualize the results. And as a complement to the Data Explorer, we are also launching an AI Assistant, which uses Cloudflare Workers AI to translate a user’s natural language statements or questions into the appropriate Radar API calls, the results of which are visualized in the Data Explorer. Below, we introduce the AI Assistant and Data Explorer, and also dig into how we used Cloudflare Developer Platform tools to build the AI Assistant.
Ask the AI Assistant
Sometimes, a user may know what they are looking for, but aren’t quite sure how to build the relevant API query by selecting from the available options and filters. (The sheer number may appear overwhelming.) In those cases, they can simply pose a question to the AI Assistant, like “Has there been an uptick in malicious email over the last week?” The AI Assistant makes a series of Workers AI and Radar API calls to retrieve the relevant data, which is visualized within seconds:
The AI Assistant pane is found on the right side of the page in desktop browsers, and appears when the user taps the “AI Assistant” button on a mobile browser. To use the AI Assistant, users just need to type their question into the “Ask me something” area at the bottom of the pane and submit it. A few sample queries are also displayed by default to provide examples of how and what to ask, and clicking on one submits it.
The submitted question is evaluated by the AI Assistant (more below on how that happens), and the resulting visualization is displayed in the Results section of the Data Explorer. In addition to the visualization of the results, the appropriate Data, Filter, and Compare options are selected in the Query section above the visualization, allowing the user to further tune or refine the results if necessary. The Keep current filters toggle within the AI Assistant pane allows users to build on the previous question. For example, with that toggle active, a user could ask “Traffic in the United States”, see the resultant graph, and then ask “Compare it with traffic in Mexico” to add Mexico’s data to the graph.
Building a query directly
For users that prefer a more hands-on approach, a wide variety of Radar datasets are available to explore, including traffic metrics, attacks, Internet quality, email security, and more. Once the user selects a dataset, the Breakdown By: dropdown is automatically populated with relevant options (if any), and Filter options are also dynamically populated. As the user selects additional options, the visualization in the Result section is automatically updated.
In addition to building the query of interest, Data Explorer also enables the user to compare the results, both against a specific date range and/or another location or autonomous system (AS). To compare results with the immediately previous period (the last seven days with the seven days before that, for instance), just toggle on the Previous period switch. Otherwise, clicking on the Date Range field brings up a calendar that enables the user to select a starting date — the corresponding date range is intelligently selected, based on the date range selected in the Filter section. To compare results across locations or ASNs, clicking on the “Location or ASN” field brings up a search box in which the user can enter a location (country/region) name, AS name, or AS number, with search results updating as the user types. Note that locations can be compared with other locations or ASes, and ASes can be compared with other ASes or locations. This enables a user, for example, to compare trends for their ISP with trends for their country.
Visualizing the results
Much of the value of Cloudflare Radar comes from its visualizations – the graphs, maps, and tables that illustrate the underlying data, and Data Explorer does not disappoint here. Depending on the dataset and filters selected, and the volume of data returned, results may be visualized in a time series graph, bar chart, treemap, or global choropleth map. The visualization type is determined automatically based on the contents of the API response. For example, the presence of countryalpha2 keys in the response means a choropleth map will be used, the presence of timestamps in the response means a line graph (“xychart”) should be shown, and more than 40 items in the response selects a treemap as the visualization type.
To illustrate the extended visualizations available in Data Explorer, the figure below is an expanded version of one that would normally be found on Radar’s Adoption & Usage page. The “standard” version of the graph plots the shares of the HTTP versions over the last seven days for the United States, as well as the summary share values. In this extended version of the graph generated in the Data Explorer, we compare data for the United States with HTTP version share data for AS701 (Verizon), for both the past seven days and the previous seven-day period. In addition to the comparisons plotted on the time series graph, the associated summary values are also compared in an accompanying bar chart. This comprehensive visualization makes comparisons easy.
For some combinations of datasets/filters/comparisons, time series graphs can get quite busy, with a significant number of lines being plotted. To isolate just a single line on the graph, double-click on the item in the legend. To add/remove additional lines back to/from the graph, single-click on the relevant legend item.
Similar to other visualizations on Radar, the resulting graphs or maps can be downloaded, copied, or embedded into another website or application. Simply click on the “Share” button above the visualization card to bring up the Share modal dialog. We hope to see these graphs shared in articles, blog posts, and presentations, and to see embedded visualizations with real-time data in your portals and operations centers!
Still want to use the API? No problem.
Although Data Explorer was designed to simplify the process of building, and viewing the results of, more complex API queries, we recognize that some users may still want to retrieve data directly from the API. To enable that, Data Explorer’s API section provides copyable API calls as a direct request URL and a cURL command. The raw data returned by the query is also available to copy or download as a JSON blob, for those users that want to save it locally, or paste it into another application for additional manipulation or analysis.
How we built the AI Assistant
Knowing all that AI is capable of these days, we thought that creating a system for an LLM to answer questions didn’t seem like an overly complex task. While there were some challenges, Cloudflare’s developer platform tools thankfully made it fairly straightforward.
LLM-assisted API querying
The main challenge we encountered in building the API Assistant was the large number of combinations of datasets and parameters that can potentially be visualized in the Data Explorer. There are around 100 API endpoints from which the data can be fetched, with most able to take multiple parameters.
There were a few potential approaches to getting started. One was to take a previously trained LLM and further train it with the API endpoint descriptions in order to have it return the output in the required structured format which would then be used to execute the API query. However, for the first version, we decided against this approach of fine-tuning, as we wanted to quickly test a few different models supported by Workers AI, and we wanted the flexibility to easily add or remove parameter combinations, as Data Explorer development was still under way. As such, we decided to start with prompt engineering, where all the endpoint-specific information is placed in the instructions sent to the LLM.
Putting the full detailed description of the API endpoints supported by the Data Explorer into the system prompt would be possible for an LLM with a larger context window (the number of tokens the model takes as input before generating output). Newer models are getting better with the needle in a haystack problem, which refers to the issue whereby LLMs do not retrieve information (the needle) equally well if it is placed in different positions within the long textual input (the haystack). However, it has been empirically shown that the position of information within the large context still matters. Additionally, many of the Radar API endpoints have quite similar descriptions, and putting all the descriptions in a single instruction could be more confusing for the model, and the processing time also increases with larger contexts. Based on this, we adopted the approach of having multiple inference calls to an LLM.
First, when the user enters a question, a Worker sends this question and a short general description of the available datasets to the LLM, asking it to determine the topic of the question. Then, based on the topic returned by the model, a system prompt is generated with the endpoint descriptions, including only those related to the topic. This prompt, along with the original question, is sent to the LLM asking it to select the appropriate endpoint and its specific parameters. At the same time, two parallel inference calls to the model are also made, one with the question and the system prompt related to the description of location parameters, and another with the description of time range parameters. Then, all three model outputs are put together and validated.
If the final output is a valid dataset and parameter combination, it is sent back to the Data Explorer, which executes the API query and displays the resulting visualization for the user. Different LLMs were tested for this task, and at the end, openhermes-2.5-mistral-7b, trained on code datasets, was selected as the best option. To give the model more context, not only is the user’s current question sent to the model, but the previous one and its response are as well, in case the next question asked by the user is related to the previous one. In addition, calls to the model are sent through Cloudflare’s AI Gateway, to allow for caching, rate limiting, and logging.
After the user is shown the result, they can indicate whether what was shown to them was useful or not by clicking the “thumbs up” or “thumbs down” icons in the response. This rating information is saved with the original question in D1, our serverless SQL database, so the results can be analyzed and applied to future AI Assistant improvements.
The full end-to-end data flow for the Cloudflare Radar AI Assistant is illustrated in the diagram below.
When the LLM doesn’t know the answer
In some cases, however, the LLM may not “know” the answer to the question posed by the user. If the model does not generate a valid final response, then the user is shown three alternative questions. The intent here is to guide the user into asking an answerable question — that is, a question that is answerable with data from Radar.
This is achieved using a previously compiled (static) list of various questions related to different Radar datasets. For each of these questions, their embedding is calculated using an embeddings model, and stored in our Vectorizevector database. “Embeddings” are numerical representations of textual data (vectors) capturing their semantic meaning and relationships, with similar text having vectors that are closer. When a user’s question does not generate a valid model response, the embedding of that question is calculated, and its vector is compared against all the stored vectors from the vector database, and the three most similar ones are selected. These three questions, determined to be similar to the user’s original question, are then shown to the user.
There are also cases when the LLM gives answers which do not correspond to what the user asked, as hallucinations are currently inevitable in LLMs, or when time durations are calculated inaccurately, as LLMs sometimes struggle with mathematical calculations. To help guard against this, AI Assistant responses are first validated against the API schema to confirm that the dataset and the parameter combination is valid. Additionally, Data Explorer dropdown options are automatically populated based on the AI Assistant’s response, and the chart titles are also automatically generated, so the user always knows exactly what data is shown in the visualization, even if it might not answer their actual question.
Looking ahead
We’re excited to enable more granular access to the rich datasets that currently power Cloudflare Radar. As we add new datasets in the future, such as DNS metrics, these will be available through Data Explorer and AI Assistant as well.
As noted above, Radar offers a predefined set of visualizations, and these serve as an excellent starting point for further exploration. We are adding links from each Radar visualization into Data Explorer, enabling users to further analyze the associated data to answer more specific questions. Clicking the “pie chart” icon next to a graph’s description brings up a Data Explorer page with the relevant metrics, options, and filters selected.
Correlating observations across two different metrics is another capability that we are also working on adding to Data Explorer. For example, if you are investigating an Internet disruption, you will be able to plot traffic trends and announced IP address space for a given country or autonomous system on the same graph to determine if both dropped concurrently.
But for now, use the Data Explorer and AI Assistant to go beyond what Cloudflare Radar offers, finding answers to your questions about what’s happening on the Internet. If you share Data Explorer visualizations on social media, be sure to tag us: @CloudflareRadar (X), noc.social/@cloudflareradar (Mastodon), and radar.cloudflare.com (Bluesky). You can also reach out on social media, or contact us via email, with suggestions for future Data Explorer and AI Assistant functionality.
When it comes to the Internet, everyone wants to be the fastest. At Cloudflare, we’re no different. We want to be the fastest network in the world, and are constantly working towards that goal. Since June 2021, we’ve been measuring and ranking our network performance against the top global networks. We use this data to improve our performance, and to share the results of those initiatives.
In this post, we’re going to share with you how our network performance has changed since our last post in March 2024, and discuss the tools and processes we are using to assess network performance.
Digging into the data
Cloudflare has been measuring network performance across these top networks from the top 1,000 ISPs by estimated population (according to the Asia Pacific Network Information Centre (APNIC)), and optimizing our network for ISPs and countries where we see opportunities to improve. For performance benchmarking, we look at TCP connection time. This is the time it takes an end user to connect to the website or endpoint they are trying to reach. We chose this metric to show how our network helps make your websites faster by serving your traffic where your customers are. Back in June 2021, Cloudflare was ranked #1 in 33% of the networks.
As of September 2024, examining 95th percentile (p95) TCP connect times measured from September 4 to September 19, Cloudflare is the #1 provider in 44% of the top 1000 networks:
This graph shows that we are fastest in 410 networks, but that would only make us the fastest in 41% of the top 1,000. To make sure we’re looking at the networks that eyeballs connect from, we exclude networks like transit networks that aren’t last-mile ISPs. That brings the number of measured networks to 932, which makes us fastest in 44% of ISPs.
Now let’s take a look at the fastest provider by country. The map below shows the top network by 95th percentile TCP connection time, and Cloudflare is fastest in many countries. For those where we weren’t, we were within a few milliseconds of our closest competitor.
This color coding is generated by grouping all the measurements we generate by which country the measurement originates from, and then looking at the 95th percentile measurements for each provider to see who is the fastest. This is in contrast to how we measure who is fastest in individual networks, which involves grouping the measurements by ISP and measuring which provider is fastest. Cloudflare is still the fastest provider in 44% of the measured networks, which is consistent with our March report. Cloudflare is also the fastest in many countries, but the map is less orange than it was when we published our measurements from March 2024:
This can be explained by the fact that the fastest provider in a country is often determined by latency differences so small it is often less than 5% faster than the second-fastest provider. As an example, let’s take a look at India, a country where we are now the fastest:
India performance by provider
Rank
Entity
95th percentile TCP Connect (ms)
Difference from #1
1
Cloudflare
290 ms
–
2
Google
291 ms
+0.28% (+0.81 ms)
3
CloudFront
304 ms
+4.61% (+13 ms)
4
Fastly
325 ms
+12% (+35 ms)
5
Akamai
373 ms
+29% (+83 ms)
In India, we are the fastest network, but we are beating the runner-up by less than a millisecond, which shakes out to less than 1% difference between us and the number two! The competition for the number one spot in many countries is fierce and sometimes can be determined by what days you’re looking at the data, because variance in connectivity or last-mile outages can materially impact this data.
For example, on September 17, there was an outage on a major network in India, which impacted many users’ ability to access the Internet. People using this network were significantly impacted in their ability to connect to Cloudflare, and you can actually see that impact in the data. Here’s what the data looked like on the day of the outage, as we dropped from the number one spot that day:
India performance by provider
Rank
Entity
95th percentile TCP Connect (ms)
Difference from #1
1
Google
219 ms
–
2
CloudFront
230 ms
+5% (+11 ms)
3
Cloudflare
236 ms
+7.47% (+16 ms)
4
Fastly
261 ms
+19% (+41 ms)
5
Akamai
286 ms
+30% (+67 ms)
We were impacted more than other providers here because our automated traffic management systems detected the high packet loss as a result of the outage and aggressively moved all of our traffic away from the impacted provider. After review internally, we have identified opportunities to improve our traffic management to be more fine-grained in our approach to outages of this type, which would help us continue to be fast despite changes in the surrounding ecosystem. These unplanned occurrences can happen to any network, but these events also provide us opportunities to improve and mitigate the randomness we see on the Internet.
The phenomenon of providers having fluctuating latencies can also work against us. Consider Poland, a country where we were the fastest provider in March, but are no longer the fastest provider today. Digging into the data a bit more, we can see that even though we are no longer the fastest, we’re slower by less than a millisecond, giving us confidence that our architecture is optimized for performance in the region:
Poland performance by provider
Rank
Entity
95th percentile TCP Connect (ms)
Difference from #1
1
Google
246 ms
–
2
Cloudflare
246 ms
+0.15% (+0.36 ms)
3
CloudFront
250 ms
+1.7% (+4.17 ms)
4
Akamai
272 ms
+11% (+26 ms)
5
Fastly
295 ms
+20% (+50 ms)
These nuances in the data can make us look slower in more countries than we actually are. From a numbers’ perspective we’re neck-and-neck with our competitors and still fastest in the most networks around the world. Going forward, we’re going to take a longer look at how we’re visualizing our network performance to paint a clearer picture for you around performance. But let’s go into more about how we actually get the underlying data we use to measure ourselves.
How we measure performance
When you see a Cloudflare-branded error page, something interesting happens behind the scenes. Every time one of these error pages is displayed, Cloudflare gathers Real User Measurements (RUM) by fetching a tiny file from various networks, including Cloudflare, Akamai, Amazon CloudFront, Fastly, and Google Cloud CDN. Your browser sends back performance data from the end-user’s perspective, helping us get a clear view of how these different networks stack up in terms of speed. The main goal? Figure out where we’re fast, and more importantly, where we can make Cloudflare even faster. If you’re curious about the details, the original Speed Week blog post dives deeper into the methodology.
Using this RUM data, we track key performance metrics such as TCP Connection Time, Time to First Byte (TTFB), and Time to Last Byte (TTLB) for Cloudflare and the other networks.
Starting from March, we fixed the list of networks we look at to be the top 1000 networks by estimated population as determined by APNIC, and we removed networks that weren’t last-mile ISPs. This change makes our measurements and reporting more consistent because we look at the same set of networks for every reporting cycle.
How does Cloudflare use this data?
Cloudflare uses this data to improve our network performance in lagging regions. For example, in 2022 we recognized that performance on a network in Finland was not as fast as some comparable regions. Users were taking 300+ ms to connect to Cloudflare at the 95th percentile:
Performance for Finland network
Rank
Entity
95th percentile TCP Connect (ms)
Difference from #1
1
Fastly
15 ms
–
2
CloudFront
19 ms
+19% (+3 ms)
3
Akamai
20 ms
+28% (+4.3 ms)
4
Google
72 ms
+363% (+56 ms)
5
Cloudflare
368 ms
+2378% (+353 ms)
After investigating, we recognized that one major network in Finland was seeing high latency due to issues resulting from congestion. Simply put, we were using all the capacity we had. We immediately planned an expansion, and within two weeks of that expansion completion, our latency decreased, and we became the fastest provider in the region, as you can see in the map above.
We are constantly improving our network and infrastructure to better serve our customers. Data like this helps us identify where we can be most impactful, and improve service for our customers.
What’s next
We’re sharing our updates on our journey to become as fast as we can be everywhere so that you can see what goes into running the fastest network in the world. From here, our plan is the same as always: identify where we’re slower, fix it, and then tell you how we’ve gotten faster.
Much has changed in the 2024 United States presidential election since the June 27 debate between Donald Trump and Joe Biden, then the presumptive nominees for the November election. Now, over two months later, on September 10, the debate was between Kamala Harris, the Democratic nominee, and Donald Trump, the Republican nominee. In this post, we will explore the event’s impact on Internet traffic in specific states where there was a bigger impact than during the Biden-Trump debate, as well as examine cyberattacks, email phishing trends, and general DNS data on candidates, news, and election-related activity.
Typically, we have observed that election days don’t come with significant changes to Internet traffic, and the same is true for debates. Yet, debates can also draw attention that impacts traffic, especially when there is heightened anticipation. The 2024 debates were not only aired on broadcast and cable television, but also streamed on platforms like YouTube, increasing their reach and impact.
Key takeaways:
The September 10 Harris-Trump debate caused bigger drops in Internet traffic in the US than the Biden-Trump debate on June 27.
There was also a noticeable increase in DNS traffic to both Kamala Harris-related and Donald Trump-related domains, with Trump-related DNS traffic peaking around the start of the debate and Harris-related DNS traffic peaking after the debate ended, around the time Taylor Swift announced she was endorsing Harris.
We also observed increases in DNS traffic to US news media outlets and election-related domains right after the debate ended.
Donald Trump remains the candidate with the most mentions in email subjects and the highest percentages of emails classified as spam (26.7%) and malicious (2.4%). Since mid-August, there has been a slight increase in the percentage of spam and malicious emails mentioning Kamala Harris.
Traffic drop in the US
During the September 10, 2024, debate between Harris and Trump, hosted by ABC News at 21:00 EST (01:00 UTC) in Philadelphia, Pennsylvania, Cloudflare noted a trend similar to the Biden-Trump debate, with a clear drop in nationwide Internet requests, falling as much as 9% below the same time a week prior at 21:15 EST (01:15 UTC). At the end of the debate, around 22:45 EST (02:45 UTC), the drop was less evident, at just 2%. Traffic increased slightly just after the debate.
Note: there were two four-minute breaks during the debate, at around 22:00 and 22:30, and our data here has 15-minute granularity.
There’s a clear difference between this second debate, with a drop of up to 9%, and the first one between Biden and Trump on June 27, when the traffic dropped just 2% below the same time a week prior. Interestingly, the biggest drop occurred at the same time in both debates, right after they started, at 21:15 EST (01:15 UTC).
Internet traffic dips across US states
Traffic shifts at the time of the debate, as compared to the previous week, can reveal more detail at a state-level perspective than at the country level. The map below summarizes traffic changes observed at a state level. A key observation is that traffic declines at a state level were much more pronounced during the Harris-Trump debate, than during the Biden-Trump debate in late June.
(Source: Cloudflare; created with Datawrapper)
The most significant traffic drops were observed in Vermont (-25%), Montana (-22%), and Idaho (-19%). More populous states such as California (-11%), Texas (-10%), and New York (-14%) also experienced notable declines in traffic.
Just for comparison, here’s the state map from that June 27 Biden-Trump debate:
(Source: Cloudflare; created with Datawrapper)
The initial minutes of the Harris-Trump debate triggered the largest traffic declines in most states, at least up until the first break, at around 21:30 ET (01:30 UTC).
In the next table, we provide a detailed breakdown of the same perspective shown on the US map ordered by the magnitude of the drop in traffic. We include the time of the biggest traffic drop compared to the previous week, at a 5-minute granularity, and also the percentage of the drop compared to the previous week. As noted above, the largest declines appeared to occur earlier in the debate.
State
Drop in traffic (%)
Local Time
UTC
Vermont
-25%
21:05 EDT
1:05
Montana
-22%
19:10 MDT
1:10
Idaho
-19%
19:10 MDT
1:10
Wyoming
-19%
19:15 MDT
1:15
North Dakota
-18%
20:15 CDT
1:15
Delaware
-15%
21:20 EDT
1:20
Illinois
-15%
20:20 CDT
1:20
Mississippi
-14%
20:05 CDT
1:05
New York
-14%
21:05 EDT
1:05
Rhode Island
-14%
21:45 EDT
1:45
West Virginia
-14%
21:15 EDT
1:15
Alabama
-13%
20:05 CDT
1:05
Georgia
-13%
21:20 EDT
1:20
South Carolina
-13%
21:15 EDT
1:15
Virginia
-13%
21:15 EDT
1:15
Colorado
-12%
19:45 MDT
1:45
Connecticut
-12%
21:05 EDT
1:05
Nevada
-12%
18:20 PDT
1:20
New Jersey
-12%
21:20 EDT
1:20
Alaska
-11%
17:15 AKDT
1:15
California
-11%
18:15 PDT
1:15
Florida
-11%
21:05 EDT
1:05
North Carolina
-11%
21:05 EDT
1:05
Wisconsin
-11%
20:20 CDT
1:20
Arkansas
-10%
20:05 CDT
1:05
District of Columbia
-10%
21:55 EDT
1:55
Missouri
-10%
20:25 CDT
1:25
Oregon
-10%
18:40 PDT
1:40
Pennsylvania
-10%
21:05 EDT
1:05
South Dakota
-10%
20:20 CDT
1:20
Texas
-10%
20:05 CDT
1:05
Maryland
-9%
21:20 EDT
1:20
Massachusetts
-9%
21:20 EDT
1:20
New Hampshire
-9%
21:05 EDT
1:05
Oklahoma
-9%
20:05 CDT
1:05
Arizona
-8%
18:15 MST
1:15
Indiana
-8%
21:05 EDT
1:05
Iowa
-8%
20:05 CDT
1:05
Kentucky
-8%
21:05 EDT
1:05
Maine
-8%
21:15 EDT
1:15
Nebraska
-8%
19:45 MDT
1:45
Kansas
-7%
20:25 CDT
1:25
Louisiana
-7%
20:20 CDT
1:20
Michigan
-7%
21:20 EDT
1:20
Minnesota
-7%
20:30 CDT
1:30
New Mexico
-7%
19:25 MDT
1:25
Washington
-7%
18:05 PDT
1:05
Hawaii
-6%
15:20 HST
1:20
Ohio
-6%
21:15 EDT
1:15
Tennessee
-6%
20:05 CDT
1:05
Utah
-6%
19:10 MDT
1:10
Swing state drops in traffic higher than first debate
The seven swing states that are said to be decisive in the election — Arizona, Georgia, Michigan, Nevada, North Carolina, Pennsylvania, and Wisconsin — each saw traffic drop between 8% and 13%, which is more than during the Biden-Trump debate (between 5% and 8% at that time). Here’s a more focused view of those swing states for easier visualization:
State
Drop in traffic
Local Time
UTC
Arizona
-8%
18:15 MST
1:15
Georgia
-13%
21:20 EDT
1:20
Michigan
-7%
21:20 EDT
1:20
Nevada
-12%
18:20 PDT
1:20
North Carolina
-11%
21:05 EDT
1:05
Pennsylvania
-10%
21:05 EDT
1:05
Wisconsin
-11%
20:20 CDT
1:20
DNS trends
Shifting our attention to domain trends, our 1.1.1.1 resolver data highlights a more targeted impact during and around the debate. Let’s start with Kamala Harris-related insights.
Harris and the Taylor Swift effect
Since July 21, the date of Biden’s withdrawal and endorsement of Harris, daily DNS traffic to Harris-related domains has significantly increased, with notable peaks on August 30 (the day after the Harris-Walz interview on CNN) and September 10 (the debate with Trump).
From an hourly perspective, the impact of the debate on Kamala Harris-related sites is evident, with increased DNS traffic throughout the day (September 10). The peak occurred at the debate’s start (21:00 ET / 01:00 UTC) with a 54% increase from the previous week, and again after it ended (23:00 ET / 03:00 UTC) with a 56% rise. This spike coincided with Taylor Swift’s endorsement of Kamala Harris.
Trump and the Elon Musk interview effect
Donald Trump, having a longer-standing campaign and websites compared to Kamala Harris, shows different trends. Aggregated daily DNS traffic to Trump-related domains has also increased in recent months. Significant peaks were observed on July 15 (two days after the assassination attempt), then during the Republican National Convention (August 19-22), with the highest spike occurring on August 12, following Elon Musk’s interview with Trump on X.
Hourly data shows the debate’s impact on Trump-related sites with a noticeable increase around the debate’s start (21:00 ET / 01:00 UTC), where DNS traffic was 46% higher than the previous week. This elevated traffic continued for a few hours, after the debate ended.
From news to election-related sites
Like previous US election-related events, the debate generated significant interest in US news organizations, leading to a rise in aggregated DNS traffic to general US news sites. This increase peaked during the debate at 22:00 ET (02:00 UTC), with DNS traffic 62% higher than the previous week. The elevated DNS traffic began before the debate and persisted afterward, with a 19% increase at 20:00 ET (00:00 UTC) and a 25% increase at 00:00 ET (04:00 UTC).
Microblogging social platforms like X or Threads outperformed their previous week’s traffic throughout the debate, peaking at 16% growth around 22:00 ET (02:00 UTC).
Additionally, there was a notable increase in DNS traffic to election-related websites, including official voting registration and election sites. During the morning of September 10 in the US, DNS traffic was 38% higher at 10:00 ET (14:00 UTC), with a significant spike at 23:00 ET (03:00 UTC) right after the debate, where DNS traffic surged by 76% compared to the previous week.
Harris-Trump: spam and malicious emails
From a cybersecurity perspective, trending events, topics, and individuals often attract more emails, including malicious, phishing, and spam messages. Our earlier analysis covered email trends involving “Joe Biden” and “Donald Trump” since January. We’ve since updated it to include Kamala Harris after the Democratic Convention.
From June 1, 2024, through August 21, Cloudflare’s Cloud Email Security service processed over 16 million emails that included the names “Donald Trump”, “Joe Biden”, or “Kamala Harris” in the subject, with 8.7 million referencing Trump, 4.8 million referencing Biden, and 3 million referencing Harris.
The chart below highlights a surge in emails mentioning Trump in mid-July, contrasting with a drop in the number of emails mentioning Biden in the subject and an increase in emails mentioning Harris.
Since July 21, following changes in the presumptive Democratic candidate, over 4.5 million emails mentioned “Donald Trump,” over 1.5 million mentioned “Joe Biden,” and around 2.8 million mentioned “Kamala Harris” in the subject. Of these, 26.7% of emails with Trump’s name were classified as spam, and 2.4% were classified as malicious. For Kamala Harris, 1.1% were classified as spam and 0.2% were classified as malicious, while Biden’s figures were 1.1% for spam and 0.1% for malicious.
Since mid-August, there has been a slight increase in the percentage of spam and malicious emails mentioning Kamala Harris. Trump remains the candidate with the most mentions in email subjects and the highest percentages of emails classified as spam and malicious.
September attacks on political and news sites
In our blog posts about several of the 2024 elections, we have noted that attacks on politically-related websites have remained a significant threat this year. In Europe, we’ve seen political parties and associated websites targeted around elections. We previously reported on DDoS attacks around the Republican National Convention and Democratic National Convention.
In our post about the Democratic National Convention, we showed that during late July and August, Cloudflare blocked DDoS attacks targeting three US politically related organizations, including a site associated with one of the major parties, with attacks occurring just before the Democratic Convention.
The largest DDoS attack recorded in recent days against politically-related websites targeted specifically a US political-party related website on September 4, peaking at 140,000 requests per second (rps) and lasting about 5 minutes.
But it’s not only US politically-related websites that could be the target of cyber attacks. News organizations are often attacked during relevant events, as we saw during the first year of the war in Ukraine, for example. Already in September, we’ve seen an example of a relevant US news organization that covers politics being the target of a DDoS attack on September 3, peaking at 343,000 requests per second (rps) and lasting about 5 minutes.
As highlighted in our Q2 DDoS report, most DDoS attacks are short-lived, as exemplified by the two mentioned attacks. Also, 81% of HTTP DDoS attacks peak at under 50,000 requests per second (rps), and only 7% reach between 100,000 and 250,000 rps. While a 140,000 rps attack might seem minor to Cloudflare, it can be devastating for websites not equipped to handle such high levels of traffic.
Conclusion
In this analysis of the Harris-Trump debate, we’ve observed that the September 10 debate caused bigger drops in traffic in the US than the Biden-Trump debate in late June. There was also a noticeable increase in DNS traffic to both Kamala Harris-related and Donald Trump-related domains, as well as to US news media outlets and election-related domains — in this case, right after the debate ended.
If you’re interested in more trends and insights about the Internet and elections, check out Cloudflare Radar, specifically our 2024 Elections Insights report. It will be updated throughout the year as elections (or election-related events) occur.
The Paris 2024 Summer Olympics wrapped up on August 11, 2024, with the Olympic flag being lowered in the Stade de France after 16 days of competitions. With 329 events across 32 sports, over 10,000 athletes from 204 nations participated in the pursuit of medals and glory, creating some viral online moments along the way. In this post, we turn our attention to the closing ceremony, the impact of various Olympic moments on Internet traffic, and the cyber attacks faced by sponsors. We also examine email trends related to the Olympics, including mentions of Simone Biles, Snoop Dogg, and Imane Khelif.
Cloudflare has a global presence with data centers in over 330 cities, supporting millions of customers with different tools and products, which provides a global view of what’s happening on the Internet. This is helpful for improving security, privacy, efficiency, and speed, but also for observing Internet disruptions and traffic trends.
In our previous blog post about the opening ceremony and the early days of the event, we showed how France was impacted by the Olympics, with clear drops in traffic during the main events. The opening ceremony caused the most significant drop—traffic decreased by as much as 20% compared to the previous week. Other countries were also less online during that time, spending more time on broadcast TV.
Closing ceremony impact in France
The moment that the Golden Voyager (a golden dancing character) descended from the sky during the closing ceremony. Captured in a photo taken by Cloudflare CEO Matthew Prince, who was in attendance.
More than two weeks after the Summer Olympics began, the 3-hour closing ceremony on August 11, 2024, had a similar impact as the opening ceremony did on Internet traffic in France, although less pronounced. Internet traffic dropped by as much as 14% compared to the previous week at the start of the ceremony, around 19:15 UTC. Here is a breakdown of the top three traffic drops compared to the previous week during the ceremony, detailing the events occurring at those times. Our data provides insights with 15-minute granularity.
Moments of the closing ceremony by traffic drop in France
Time of drop (UTC)
Drop %
Events at the time
#1
~19:15
-14%
Léon Marchand, France’s swimming star, carried a lantern from the Cauldron at the Jardins des Tuileries to the Stade de France. Flags of all National Olympic Committees entered the stadium, followed by the athletes.
#2
~20:15
-13%
A Golden Voyager, inspired by French history, descended from the sky, followed by Nike, the Goddess of Victory. In the stands, LED bracelets—similar to those used at Taylor Swift concerts—created images of athletes, doves of peace, and the Olympic Rings.
#3
~21:30
-10%
Californian artist H.E.R. performed the U.S. national anthem and introduced Tom Cruise, who performed Mission Impossible stunts to transport the Olympic flag from Paris to Los Angeles.
During the closing ceremony, from 19:00 to 22:00 UTC, traffic in France was significantly lower than the previous week, down between 3% – 14%. The decreases were less pronounced during the middle and end of the event. Internet requests increased during band performances and the official closing speeches. Traffic also rose during Yseult’s finale, singing a rendition of Frank Sinatra’s “My Way,” contrasting with the significant drop during Celine Dion’s performance at the end of the opening ceremony.
In exploring traffic trends for other countries, we found that the closing ceremony didn’t have as clear an impact as the opening event did.
Taking a broader look at traffic in France during the entire Olympic period, daily traffic dropped by as much as 8% on July 28 but remained fairly stable afterward, with a 3% drop on August 8.
Mobile device use rose in France
Mobile device traffic share continued to grow during the event, with more people using mobile devices to access the Internet. This trend of more mobile use in France aligns not only with more tourists and visitors in the country during the Olympics – visitors more typically use mobile devices to access the Internet – but also with French people taking vacations and working less during this time. Weekly mobile device traffic share in France in mid-June was 49%, and since the Olympics started, it has increased to between 53% and 54%.
In France, mobile device use is higher on weekends. However, looking at daily trends, mobile traffic share on weekdays was clearly higher after July 26, when the Olympics began.
Parisians left, Olympic tourists arrived
We’ve seen before that Parisians appeared to left town (and the region) just before the Olympics. In the Paris region of Île-de-France, with the Olympics, traffic during the first week of the event dropped as much as 6% on July 30, compared to the previous week. Traffic picked up a bit on the second weekend of the Olympics but dropped even more during the second and final week.
The chart below illustrates daily traffic to the Île-de-France region, with a noticeable decline visible during the weekend before the Olympics that was more pronounced during the event.
Weekly traffic dropped 8% the week the Olympics started and remained stable the following week. Even so, by August 4, the last week of the Olympics, traffic was 23% lower in the Île-de-France region than in the week of June 30, when it was at its highest in recent weeks.
Significant moments: from Simone Biles to breakdancing debut
Below, we highlight specific Olympic events affecting Internet traffic that we were able to observe in our data from different locations (ordered by the numbers of medals in the event), starting from the first full competition day on Saturday, July 27, 2024.
Host nation France was clearly the one with more significant impacts to Internet traffic during relevant moments of the Olympics.
United States: The artistic gymnastics competition featuring four-time Olympic gold medalist Simone Biles had a greater impact on U.S. Internet traffic than the opening ceremony. On July 26-28, traffic dipped most significantly during Biles’ events. On the 28th, at 10:00 UTC, during her beam routine, traffic was already 4% lower than the previous week. It dropped by 6% at 10:45 UTC during her floor and vault routines.
On July 29, at 19:30 UTC, traffic dropped 4% during the swimming event where Ryan Murphy won the bronze medal in the men’s 100 m backstroke final.
Another notable drop occurred on August 10, with a 7% decrease around 15:00 UTC during the women’s football gold medal match between Brazil and the USA. Later that day, during the men’s basketball gold medal game between France and the USA, traffic dropped by as much as 6%.
Great Britain: The first weekend of the Olympics saw clear drops in traffic, with a 10% decrease compared to the previous week around 15:00 UTC on July 28, 2024. British athletes participated in several events during those busy days. Traffic the following weekend was slightly higher than in the first Olympic weekend but dropped again on the final day, August 11.
France: As previously noted, French swimmer Léon Marchand’s gold medal and Olympic record in the men’s 400-meter individual medley on July 28 had the most significant impact on French traffic during the Olympics, aside from the 20% drop seen during the opening ceremony. Traffic fell by 17% at 18:30 UTC during his event—the same level of drop seen during the closing ceremony. Similar impacts occurred during other swimming events:
July 29, 19:45 UTC, 14% drop during the Women’s 100 m Backstroke Semifinals featuring Yohann Ndoye-Brouard.
July 30, 19:00 UTC, 12% drop during the Men’s 200 m Butterfly Semifinals with Léon Marchand.
July 31, 18:30-20:30 UTC, 7% to 10% drop during the Men’s 200 m Butterfly final with Léon Marchand.
August 1, 18:45 UTC, 8% drop during swimming semifinals and finals.
Other notable drops include breakdancing:
August 9, 14:30 UTC, 10% drop during the Breaking dance debut with France’s participation.
August 10, 18:45-21:00 UTC, 7% drop during the Breaking B-Boys gold medal battle and the men’s basketball gold medal game, France vs USA.
August 11, 07:00 UTC, 8% drop during the women’s marathon.
Australia: During Mollie O’Callaghan’s victory in the women’s 200 m freestyle on July 29, at around 20:00 UTC, Australian traffic was 5% lower than the previous week, a larger drop than during the opening ceremony, which saw a 2% decrease.
On August 1, at around 18:45 UTC, traffic was 10% lower than the previous week during swimming events that led to Australia’s gold in the women’s 4x200m freestyle relay. And on August 11, at around 07:00 UTC, traffic dropped 7% compared to the previous week during the women’s marathon with Australian participants.
Japan: One of the most significant drops in traffic in Japan during the Olympics occurred on August 6, around the time Fumita Kenichiro from Japan won gold in the men’s Greco-Roman wrestling 60 kg final, followed by artistic swimming and the women’s table tennis competition, with traffic dropping 12% at 18:15 UTC.
On August 10, for several hours after 17:30 UTC, traffic in Japan was also lower than usual, with a drop of as much as 14%. This coincided with Japan’s gold medal win in the women’s javelin throw and the men’s breaking quarterfinals and semifinals.
Italy: During the event that gave Italy its first ever gold medal in artistic gymnastics, won by Alice D’Amato in the women’s balance beam event, traffic dropped 5% at around 10:45 UTC.
Netherlands: On the morning of July 28, the second full day of the Olympics, traffic in the Netherlands dropped by as much as 20% compared to the previous week, with Dutch athletes participating in several competitions.
On August 11, traffic dropped between 06:30 and 09:30 UTC, and by as much as 16% at 08:15 UTC, when Dutch runner Sifan Hassan won the gold medal in the women’s marathon.
South Korea: The Korean women’s archery team’s gold medal win on July 28 at 15:30 UTC led to an 8% drop in traffic, the most significant decrease noted in the country between July 26 and July 29.
On August 7, at 19:45 UTC, traffic was 9% lower during the Taekwondo gold medal event for Park Taejoon in the men’s -58 kg (under 58 kg) competition.
Brazil: Traffic in Brazil was 15% lower than the previous week on July 27 at around 19:30 UTC, surpassing the impact of the opening ceremony. This occurred as Brazilian swimmers Guilherme Costa and Maria Fernanda Costa competed in the men’s and women’s 400 m freestyle events.
On August 2, traffic in Brazil was 5% lower at around 00:30 UTC during the men’s surfing quarterfinals with Gabriel Medina and was 8% lower at around 01:00 UTC during the women’s surfing quarterfinals with Tatiana Weston-Webb.
Cape Verde: David Pina won the first Olympic medal in boxing for this archipelago nation off the western coast of Africa. On August 4, the amateur boxer took the bronze medal, with traffic dropping 12% in the country at around 15:00 UTC during the match.
DNS trends for official Olympic websites by country
On July 22, before the Olympics began, we reported on the heightened interest in official Olympic websites based on request data from our 1.1.1.1 DNS resolver. France initially dominated with 24% of DNS traffic, followed by the UK (20%) and the US (17%). However, when the Olympics started, the US took the lead, maintaining it throughout the event.
The following chart summarizes the highest shares of DNS request traffic by country during the Paris 2024 Summer Olympics. There was a shift in percentages that indicates a broader spread of interest across countries as the Olympics progressed, visible in the dynamic version of the map by day of the event that is available in our Paris 2024 Olympics report.
Here are the top 10 countries that during the event had more DNS traffic for Olympics official websites. The US took the “gold,” France the “silver,” and the UK the “bronze”:
United States: 18%
France: 16%
United Kingdom: 10%
Germany: 7%
Brazil: 6%
Australia: 5%
Canada: 2%
Japan: 2%
India: 2%
Russian Federation: 2%
We observed that the US overtook France for the #1 spot a few days before the event began. France also dropped to third place behind Germany on July 27, the first full day of competitions, and again after August 2, though interestingly, it returned to #2 the day after the Olympics ended.
As shown in the following daily ranking chart, the UK was #3 before the event began but dropped to #4 on August 1. Australia’s highest ranking was #3 on July 29, and #4 on August 10 and 11. Brazil’s best days, ranking #3, were on July 24-25, and on July 30, 31, and August 1.
In terms of volume of DNS traffic to our 1.1.1.1 resolver, the first full week of Olympic events saw the highest volume of requests related to official Olympic websites, with a 637% increase compared to the week before the Olympics began. This trend of peak traffic during the first week was consistent across most countries, except for Germany, Spain, India, Italy, and Russia, where the final week generated more DNS resolver traffic.
On a daily basis, worldwide DNS traffic to official Olympics domains peaked on August 2, followed by August 4 and August 5, marking the start of the second and final week of the event. Below are the top 3 days with the highest DNS traffic to official Olympic websites in the top 3 countries by traffic volume:
United States: July 30 (when the US women’s team won gold in artistic gymnastics and several medals were won in swimming), July 29, and August 5.
France: July 31 (when swimmer Léon Marchand won gold in the men’s 200 m butterfly final), July 29, and August 1.
Germany: July 27 (when swimmer Lukas Maertens won gold in the men’s 400 m freestyle final), August 8, and August 7.
Sports news sites
Looking at DNS traffic for sports news sites across different countries, the two weeks of the Olympics brought more traffic than any other week since June, including during the major football event, UEFA Euro 2024, held between June 14 and July 14. The Olympic weeks saw 17% more traffic than the week before the Olympics and 4% more DNS traffic than the best week of Euro 2024 (June 22-29).
From a daily perspective, the days with the highest traffic to sports news sites were August 10, August 3, July 28, and July 14 (related to the Euro 2024 final).
In the United States, NBC was not only the official broadcaster of the Olympics, but also created a dedicated website. NBC’s sports and NBC Olympics websites saw a significant rise in global DNS traffic, increasing up to 1,640% on July 28 compared to the previous week.
From official streaming services to Olympic sponsors
While the Olympics were still broadcast on several traditional national TV networks, streaming also played a key role, with Peacock TV (in the US and Canada) and Max (from Warner Bros. Discovery) in Europe offering several hours of Olympic content daily. The global traffic growth to these platforms was evident. On a weekly basis, DNS request traffic for streaming platforms featuring Olympic events grew by as much as 65%. Daily traffic peaked on July 30 (68% higher than the previous week), followed by July 29 and August 4. Peacock TV led over Max in terms of traffic.
Breakdancing, or “breaking,” made its first appearance in the 2024 Summer Olympics, leading to a surge in DNS traffic to breaking-related websites, particularly on August 9 and 10. Traffic peaked on August 9, with a 215% increase compared to the previous week, driven by viral moments like Australian Rachael Gunn’s performance.
How about the Paris Olympics sponsors? DNS traffic also increased, particularly in the early days of the event and the days leading up to it, with peak traffic on July 29 (15% higher than the previous week), followed by July 25 and 24 (the two days before the opening ceremony). Samsung saw the most significant impact during the early days of the Olympics, while Airbnb experienced a surge in traffic just before the opening ceremony (July 25).
Next stop: LA 2028
The closing ceremony concluded with a symbolic passing of the torch from Paris 2024 to Los Angeles 2028. Simone Biles handed the Olympic flag to Tom Cruise, who transported it Mission Impossible-style from Paris to a Venice Beach concert in LA featuring acts including the Red Hot Chili Peppers and Billie Eilish. Unsurprisingly, the official LA 2028 Olympics website saw a 1600% surge in DNS traffic on August 11 compared to the previous week.
DDoS attacks targeting Olympic-related and sponsor websites
As we observed during the 2024 elections, including the French elections, political parties are not the only targets of DDoS (Distributed Denial of Service) attacks during significant events. Attackers are aware of large global events. In a previous related blog post, we discussed attacks targeting French transportation and government websites. Below, let’s focus on Olympic-related and sponsor organizations.
In July, Cloudflare blocked a surge in DDoS attacks on Olympic partner websites – higher than in any other month of 2024. Daily DDoS attack requests jumped to 200 million, and in just 11 days of August, more DDoS requests (90 million) were blocked than in any full month in 2024 before the Olympics.
The largest spike in attacks occurred on July 29, targeting three sponsor websites simultaneously, with 84 million DDoS-related requests in a single day. The most intense DDoS attack peaked at 190,000 requests per second at 10:20 UTC.
The most significant specific attack was on the last day of the event, August 11, targeting a French transportation site. It lasted four minutes and peaked at over 500,000 requests per second at 05:09 UTC.
As highlighted in our Q2 DDoS report, most DDoS attacks are short-lived, as seen in the two mentioned attacks. While a 500,000 request per second (rps) attack is not large for Cloudflare, it can be devastating for websites not equipped to handle such traffic levels.
Analyzing the same pool of Olympic partner websites that use Cloudflare, total requests (including legitimate traffic and attacks) rose in July, reaching 4.2 billion—27% more than in May and 11% more than in June.
Rise in “Olympics” and “Paris 2024” emails
Major events often attract attention in the email realm, including spam and malicious emails, and the Olympics were no exception. From January 2024 through August 11, Cloudflare’s Cloud Email Security service processed over 1.7 million emails containing “Olympics” or “Paris 2024” in the subject. More than half of these emails (890,000) were sent during the Olympics (July 26 to August 11), with the highest volume (150,000 messages) on July 26, the day of the opening ceremony.
The week of July 22-28, coinciding with the first few days of the Olympics, saw a 304% increase in such emails compared to the previous week, and an astonishing 3111% increase compared to the busiest week in January.
Although the Olympics period (July 26 – August 11) was busy in terms of related emails, the percentages of spam and malicious messages were lower than before. However, over 6,200 emails were classified as spam (0.7%), and just 248 were identified as malicious or phishing (0.07%).
As noted in a previous blog post, since January 1, 2024, spam accounted for 1.3% of all emails with “Olympics” or “Paris 2024” in the subject, while malicious emails made up 0.1%. In a sample of 1,000 emails, roughly 13 would be spam and 1 would be malicious. The peak for malicious Olympic-related emails occurred during the week of May 6, with 0.6% classified as malicious. Although there was a decline after this peak, rates increased slightly in July, reaching 0.4% on July 8. Despite the surge in volume during the week of July 22, only 0.05% of emails were malicious.
Simone Biles and Snoop Dogg popular via email
Famous individuals are often used by attackers for email phishing. Among the athletes shining at the event, Simone Biles generated the most emails, but very few of them were spam or malicious. Biles led other popular names during the event, including those named below, ordered by number of email messages: Katie Ledecky (US), Imane Khelif (Algeria), Novak Djokovic (Serbia), Steph Curry (US), and Léon Marchand (France).
Since July 1, over 160,000 emails processed by Cloudflare’s Cloud Email Security service have included “Simone Biles” or “Biles” in the subject, with only 0.5% considered spam and 0.01% classified as malicious. (And 97% of those 160,000 emails were sent since the Olympics started on July 26.) The most emails were sent on August 5, followed by August 2 and July 28. Spam percentage peaked on July 24, with 5% of all emails considered spam.
Among famous attendees, Snoop Dogg topped the list ahead of other US team supporters like Martha Stewart, Flava Flav, and Jason Kelce. Since July, there have been over 6,600 emails with “Snoop Dogg” in the subject, with 40 classified as spam (0.6%) and 4 as malicious (0.06%).
Conclusion: from Paris to Los Angeles
The Paris 2024 Summer Olympics not only captivated millions worldwide with thrilling sports competitions, but also had a significant impact on global Internet traffic. Our data shows noticeable drops in Internet activity during key Olympic events, particularly in France, as viewers shifted from online activities to watching the games live. This trend underscores the enduring power of broadcast media during major global events, even in an increasingly digital age.
Additionally, the increase in DNS traffic for official Olympic websites and the surge in DNS traffic for streaming platforms covering the event indicates strong interest in online coverage, especially among certain audiences, complementing traditional TV viewership broadcast by national networks worldwide.
Finally, the heightened cybersecurity threats, including DDoS attacks on sponsor sites and the rise in Olympic-related emails (including spam and malicious ones), emphasize both the marketing impact of this global event and its vulnerabilities.
And after the Paris 2024 Summer Olympics, the 2024 Summer Paralympics are just around the corner (August 28-September 8), and in four years, it will be time for LA 2028.
As we’ve observed throughout the Paris 2024 Olympics, the Olympic spirit continues to capture interest and remains relevant across different media. This spirit, present for 2,800 years since Ancient Greece (dating back to 776 BC), still attracts and inspires humanity.
(Jorge Pacheco from the Cloudflare Radar team contributed to this blog post)
Historically, traffic graphs on Cloudflare Radar have displayed two metrics: total traffic and HTTP traffic. These graphs show normalized traffic volumes measured in bytes, derived from aggregated NetFlow data. (NetFlow is a protocol used to collect metadata about IP traffic flows traversing network devices.) Today, we’re adding another metric that reflects the number of HTTP requests, normalized over the same time period. By comparing bytes with requests, readers can gain additional insights into traffic patterns and user behavior. Below, we review how this new data has been incorporated into Radar, and explore HTTP request traffic in more detail.
Note that while we refer to “HTTP request traffic” in this post and on Radar, the term encompasses requests made in the clear over HTTP and over encrypted connections using HTTPS – the latter accounts for ~95% of all requests to Cloudflare during July 2024.
New and updated graphs
Graphs including HTTP request-based traffic data have been added to the Overview and Traffic sections on Cloudflare Radar. On the Overview page, the “Traffic trends” graph now includes a drop-down selector at the upper right, where you can choose between “Total & HTTP bytes” and “HTTP requests & bytes”. We explore the distinction between these further in the following sections.
The default “Total & HTTP bytes” selection displays a time series graph, showing total bytes and HTTP bytes traffic over time, as Radar has done for several years now.
Selecting “HTTP requests & bytes” from the dropdown switches the view to a time series graph that HTTP requests traffic and HTTP bytes traffic over time. In both graphs, users can click on a metric in the legend to deselect it and remove it from the graph. These (de)selections are maintained when a user chooses to download or save a graph.
In addition, we’ve added a “Protocols” summary next to the graph that shows the share of bytes over the selected time period that HTTP accounts for, and the remaining aggregate share associated with the protocols used by other non-HTTP Cloudflare services (such as DNS, WARP, etc.). For most locations or ASNs, HTTP traffic will comprise the majority share of bytes-based traffic.
On Radar’s Traffic page, we have added the HTTP requests metric to the “Traffic volume” graph at the top of the page, allowing you to see how request volume has changed during the selected time period as compared to the previous period, in addition to the changes in the bytes-based metrics.
A new standalone request-based “HTTP traffic” graph was also added to the Traffic page, just below the bytes-based “Traffic trends” graph. This new graph shows normalized HTTP request traffic volume across the selected time period, and by default, also compares it with the previous time period.
Similar to other Radar graphs, these new HTTP request-based graphs can also be downloaded, copied to the clipboard, or embedded in other websites – just click on the share icon.
As always, the underlying data is also available through the Radar API. The “HTTP requests Time Series” API endpoint returns normalized HTTP request time series data across the specified time period for the requested location or autonomous system (ASN).
What is HTTP request traffic?
An HTTP GET request is a message sent from a client (such as your web browser) to a web server (such as one operated by Cloudflare), asking for a particular resource (file). In addition to returning the requested resource, which could range from a single-pixel GIF accounting for just a few bytes, to an API call that returns a few kilobytes of data, to a multi-gigabyte software package, the Web server also returns a set of headers, which can include information about the content type, the last time the resource was modified, cookie information, cacheability, and more. While GET requests account for the overwhelming majority of HTTP request traffic, such traffic also includes other HTTP request methods including HEAD, POST, PUT, and more.
Cloudflare temporarily logs HTTP requests received by our network, including associated header information and “metadata” about the request, such as the bot score computed for the request and the associated cache status. Request logs for a customer’s web properties are available for them to download, and after processing and analysis, this data is also presented in the Analytics section of the Cloudflare dashboard. The HTTP request data now available on Radar is based on a sample of this log data, aggregated across Cloudflare’s global customer base.
The value of request-based traffic insights
Cloudflare Radar already has HTTP data, so why add more? One key reason for analyzing and including HTTP request traffic is resilience. Having multiple sources of truth with respect to HTTP traffic allows us to better and more quickly distinguish between real events (such as an Internet disruption in a given country or network) and data pipeline issues.
While bytes-based metrics provide a reasonable proxy into human (user) behavior, especially with respect to activity surrounding Internet disruptions, request-based metrics provide an even better perspective. A lot of HTTP traffic involves relatively small responses – especially API traffic, which now accounts for 60% of all traffic. Furthermore, response sizes can vary widely, ranging from a single-pixel GIF accounting for just a few bytes, to an API call that returns a few kilobytes of data, to a multi-gigabyte software package
To that end, the scope of user activity may be insufficiently reflected by a bytes-based metric, or buried in the noise, whereas request activity provides a cleaner signal and a more direct proxy for user activity. This is especially important as we examine the restoration of connectivity after an Internet disruption, attempting to ascertain when activity has returned to “expected” pre-disruption levels.
Finally, incorporating request-based traffic insights into Radar is simply extending the way that the data is already being used on the site. All the graphs, maps, and tables presented on Radar’s Adoption & Usage page, are based on analysis of HTTP request traffic, making use of information contained within request headers (such as HTTP version or user agent) or characteristics of the underlying connection (such as IP version).
Bytes vs requests – what’s the difference?
The current “HTTP traffic” view aggregates the bytes associated with HTTP requests to Cloudflare’s content delivery (CDN) services from the selected location or autonomous system (ASN). “Total traffic” aggregates this HTTP traffic along with the traffic associated with other Cloudflare services, including our 1.1.1.1 DNS resolver, authoritative DNS, WARP, and Spectrum, among others. (While Spectrum, WARP, and 1.1.1.1 also carry HTTP traffic, the share of HTTP traffic carried by these services is opaque to Radar, and isn’t accounted for as part of the HTTP traffic calculations.)
The bytes associated with a given request include the size of the request, the size of the headers associated with the response, and the size of the response itself. As noted above, the size of a file returned in response to a request can vary widely, depending on what was requested. The shape of the HTTP requests and HTTP bytes lines may be quite similar, but the potential variability in response sizes (in aggregate) can cause the lines to diverge, sometimes significantly so. For example, if an application regularly makes background requests to check for updates, the availability and subsequent download of a large file containing a software update would cause a spike in the HTTP bytes line, while the HTTP requests pattern remained consistent.
As another example, consider the graph below, capturing HTTP requests and bytes traffic trends for Portugal during the first week of August. HTTP bytes traffic initially grows each day between 06:00 and 09:00 UTC (07:00 – 10:00 local summer time), increases much more slowly until around 19:00 UTC (20:00 local summer time), and then increases rapidly before peaking around 21:00 UTC (22:00 local time). This suggests that content consumed during the workday is lighter in terms of bytes (such as API traffic, as discussed above), while evening traffic is more byte-heavy (possibly due to increased consumption of media content). In contrast, after starting to increase around 06:00 UTC (07:00 local summer time), request traffic generally sees three successively higher peaks each day – occurring around 10:00, 14:00, and 21:00 UTC respectively (11:00, 15:00, and 22:00 local summer time). These peaks are most pronounced on weekdays, but are still apparent on weekend days as well, suggesting regular patterns of user activity at those times.
It is important to remember that in looking at the “HTTP requests & bytes” graphs on Radar that they are showing two different metrics, and as such, only their shape over time is comparable, not their relative sizes. (As both metrics are normalized on a 0 to 1 (Max) scale, the lines on the graph are scaled relative to the maximum normalized value of each metric, including the previous period.)
Conclusion
The addition of HTTP request metrics to Cloudflare Radar brings additional visibility to traffic trends at a global, location, and network level, complementing the existing bytes-based HTTP traffic metrics. Derived from traffic to customer web properties, these new metrics can be found on Radar’s Overview and Traffic pages. In addition to HTTP traffic trends, visit Cloudflare Radar for additional insights around Internet disruptions, routing issues, attacks, domain popularity, and Internet quality. Follow us on social media at @CloudflareRadar (X), noc.social/@cloudflareradar (Mastodon), and radar.cloudflare.com (Bluesky), or contact us via email.
Cloudflare Radar is constantly monitoring the Internet for widespread disruptions. In mid-July, we published our Q2 2024 Internet Disruption Summary, and here we examine recent several noteworthy disruptions detected in the first month of Q3, including traffic anomalies observed in Bangladesh, Syria, Pakistan, and Venezuela.
Bangladesh
Violent student protests in Bangladesh against quotas in government jobs and rising unemployment rates led the government to order the nationwide shutdown of mobile Internet connectivity on July 18, reportedly to “ensure the security of citizens.” This government-directed shutdown ultimately became a near-complete Internet outage for the country, as broadband networks were taken offline as well. At a country level, Internet traffic in Bangladesh dropped to near zero just before 21:00 local time (15:00 UTC). Announced IP address space from the country dropped to near zero at that time as well, meaning that nearly every network in the country was disconnected from the Internet.
However, ahead of this nationwide shutdown, we observed outages across several Bangladeshi network providers, perhaps foreshadowing what was to come. At AS24389 (Grameenphone), a complete Internet outage started at 01:30 local time on July 18 (19:30 UTC on July 17), with a total loss of both Internet traffic and announced IP address space.
In the days before the shutdown, both median bandwidth and latency at a country level for Bangladesh were fairly stable. However, Cloudflare Radar’s Internet Quality measurements at a country level show a clear increase in median bandwidth and a concurrent drop in median latency, both likely due to the loss of measurements from mobile network providers as they disconnected from the Internet.
Five days after the full Internet shutdown started, broadband Internet services providers in Bangladesh began to restore connectivity on July 23. The initial restoration was characterized as a “trial run”, prioritizing banking, commercial sectors, technology firms, exporters, outsourcing providers and media outlets, according to the state minister for post, telecommunication and information technology. Announced IP address space began to increase around 19:00 local time (13:00 UTC), with traffic volumes beginning to trend upwards at that same time, as selected networks reconnected to the Internet.
Unfortunately, Syria is no stranger to Internet shutdowns, as they occur yearly during nationwide exams, implemented with the intent of preventing cheating on those exams. Our recent blog post titled Exam-ining recent Internet shutdowns in Syria, Iraq, and Algeria examined the first round of 2024 exams, which took place between May 26 and June 13.
A second round of exams, and with them, multi-hour Internet shutdowns, began on July 25, and seen in the schedules below, published by Syrian Telecom on its Facebook page (English translation via Google Lens).
The Internet shutdowns implemented for the first four days of tests are clearly visible in the graph below, occurring on July 25, 28, 29, and 30.
However, you will also note another disruption is visible in both Syria’s Internet traffic and announced IP address space shortly after the planned shutdown on July 30. According to a (translated) Facebook post from Syrian Telecom, “while performing regular maintenance on one of the air conditioners located in one of the technical halls [data centers], an explosion occurred, causing the Internet circuits to temporarily go out of service.” This issue resulted in a disruption lasting approximately eight hours, between 11:00 – 19:00 local time (08:00 – 16:00 UTC) seen in both traffic and announced IP address space graphs for AS29256 (Syrian Telecom).
Pakistan
Closing out the month, on July 31, Pakistan experienced a wide-scale Internet disruption that lasted approximately two hours, between 13:30 – 15:30 local time (08:30 – 10:30 UTC). Traffic only dropped ~45% at a country level, but AS17557 (PTCL) experienced a near complete loss of traffic, while traffic at AS24499 (Telenor Pakistan) dropped nearly 90%. Together, the two network providers serve an estimated nine million users, and are among the top five Internet service providers in the country.
It was reported that the Pakistan Telecommunication Authority (PTA) attributed the disruptions to a technical glitch in the international submarine cable affecting the Pakistan Telecommunication Company Limited (PTCL) network. However, another published report noted “According to our sources, the government’s latest firewall edition to block the content was misconfigured, resulting in Internet connectivity disruption.” (Some additional information about the firewall can be found in this article.) The graphs below are from forthcoming TCP reset/timeout data on Cloudflare Radar, and show increased numbers of connections terminating immediately after the initial synchronization (SYN) packet used to establish new TCP connections (“Post SYN”) between 13:30 – 15:30 local time (08:30 – 10:30 UTC) on PTCL and Telenor Pakistan, coincident with the observed disruption. In other words, the rate of SYN packets arriving at Cloudflare was mostly consistent during the disruption, but there was a drop in other TCP packets, suggesting that the firewall explanation may be plausible.
A Facebook post from the Pakistan Telecommunication Authority (PTA) simply highlighted that the issue had been resolved, and that “The exact issue is being investigated by PTA to avoid such instances in future.”
Regardless of the actual cause, the disruption had a clear impact on the country’s financial markets, with a published report stating “The KSE-100 index suffered a sharp decline on Wednesday, plummeting over 740 points in the final hour of trading amid a nationwide internet outage. Analysts attributed the sudden drop to panic selling as investors struggled with limited market data.”
Venezuela
In the past, some countries have implemented government-directed Internet shutdowns as a means of limiting communication about or organizing of protests and demonstrations associated with contested elections. Although such protests and demonstrations sprang up in the wake of a contested presidential election in Venezuela that took place on July 28, Internet shutdowns did not follow. However, in monitoring Internet traffic in Venezuela during the days around the election, the Cloudflare Radar team did observe several notable drops in traffic, as compared to the same times the week prior.
After surging 35% at 05:00 local time (09:00 UTC) on Sunday, July 28 (election day), traffic dropped after the polls opened, down by as much as 23% at 09:00 local time (13:00 UTC). On July 29, the day following the election, traffic was as much as 28% lower than the same time the previous week at 06:15 local time (10:15 UTC) and 18:45 local time (22:45 UTC).
And while the observed drops in traffic appeared to be organic, and not caused by an Internet shutdown, it is worth noting that multiple websites are being blocked in Venezuela. An Internet Society Pulse blog post, published two days ahead of the election, reports that “Around 60 websites are currently blocked in Venezuela, including eight media sites and three that fact-check news and misinformation.”, citing data from the Open Observatory of Network Interference (OONI).
The Paris 2024 Summer Olympics, themed “Games Wide Open” (“Ouvrons grand les Jeux”), kicked off on Friday, July 26, 2024, and will run until August 11. A total of 10,714 athletes from 204 nations, including individual and refugee teams, will compete in 329 events across 32 sports. This blog post focuses on the opening ceremony and the initial days of the event, examining associated impact on Internet traffic, especially in France, the popularity of Olympic websites by country, and the rise in Olympics-related spam and malicious emails.
Cloudflare has a global presence with data centers in over 320 cities, supporting millions of customers, which provides a global view of what’s happening on the Internet. This is helpful for improving security, privacy, efficiency, and speed, but also for observing Internet disruptions and traffic trends.
We are closely monitoring the event through our 2024 Olympics report on Cloudflare Radar and will provide updates on significant Internet trends as they develop.
An opening ceremony to remember
For the first time in modern Olympic history, the opening ceremony was held outside a stadium, lasting nearly four hours and clearly impacting Internet traffic in France. The nation’s engagement was evident during the TV broadcast, leading to noticeable traffic drops similar to those observed during Euro 2024 – we’ve seen that national TV broadcast events usually come with drops in Internet traffic.
The Olympics are more than just sporting events – they are filled with inspiring moments and stories that capture global attention in real time, and create stories that live on. Significant traffic dips during the ceremony coincided with performances by Celine Dion and Lady Gaga, the lighting of the Olympic cauldron, and John Lennon’s “Imagine” performed by Juliette Armanet. Here is a breakdown of the top five traffic drops compared to the previous week that occurred during the ceremony, detailing the events occurring at those times. Our data provides insights with 15-minute granularity.
Moments of the ceremony by traffic drop
Time of drop (UTC)
Drop %
Events at the time
#1
~21:15
-20%
The Olympic cauldron is lit and floats into the Paris sky via air balloon; Celine Dion serenades Paris from the Eiffel Tower.
#2
~17:45
-17%
Lady Gaga sings the French classic “Mon truc en plumes” by Zizi Jeanmaire.
#3
~19:45
-16.9%
Team USA boat takes to the river, followed by Team France – the last boat en route to the Eiffel Tower.
#4
~20:15
-16.9%
Dionysus performs the song “Naked” (Philippe Katerine); John Lennon’s “Imagine” is sung from the middle of the Seine by Juliette Armanet; a metal horse rides down the river.
#5
~18:00
-16.7%
As the boats continue along the Seine, around 80 artists from the Moulin Rouge perform the famous French cabaret dance, the can-can.
During the opening ceremony on July 26, between 17:30 to 21:20 UTC, traffic in France was noticeably lower than the previous week, with losses between 15% and 20%. However, there were moments with smaller drops. For example, at 19:30 UTC, traffic only fell by 4% during the middle of the boat parade of athletes on the Seine River. Right after the event, at 21:45 UTC, traffic increased by as much as 8% compared to the previous week.
The opening ceremony also resulted in a higher mobile share of traffic than usual in France. At 20:45 UTC, close to the end of the ceremony, the mobile share of Internet traffic was 61%, up from 57% the previous week.
Parisians leaving town before the Olympics
With the Olympics in Paris, many locals left the city, either for vacations or quieter places, while tourists arrived for the games. Our data shows that two French regions, Île-de-France, where Paris is located, and Grand Est, east of Paris, experienced the most significant traffic drops. The chart below illustrates daily traffic to these regions, with a noticeable decline visible during the weekend before the Olympics in Île-de-France.
Analyzing the percentage change in request traffic from the previous week, Île-de-France saw its largest drops in the first week of July (July 1-7), with a 15% decrease, and the week before the Olympics started, with an 8% decrease. Interestingly, there was no percentage change in traffic during the week of the Olympics (July 22-28) – that was also the week when most visitors for the Olympics started to arrive.
The daily share of mobile device traffic from France also reveals shifts in typical patterns, with increases noted especially after the June 30 weekend, indicative of vacation periods and leisure Internet use. Mobile device traffic peaked during the first Olympic weekend, reaching 53% on July 26, the day of the opening ceremony – higher than any previous Friday since June. On Sunday, July 28, mobile device traffic peaked at 58%, the highest since June.
Impact to Internet traffic outside of France
Globally, Internet traffic variations were less pronounced than in France. However, on July 26, the day of the opening ceremony, a noticeable global drop occurred during the event. This was particularly evident during two key moments previously highlighted: during song performances at 20:15 UTC, traffic dropped 3% compared to the previous week, and around the end of the ceremony, at 21:15 UTC, it dropped 2%.
Expanding our view to other countries, moments of significant drops in traffic during the opening ceremony were clearly visible. Below is a summary list of 30 countries selected based on their tally of Summer Olympic medals.
Country
Drop in traffic (%)
Time of drop (UTC)
United States
-4%
20:15
Great Britain
-8%
20:15
France
-20%
21:15
Germany
-4%
20:15
China
-4%
21:00
Italy
-11%
18:15
Australia
-2%
20:00
Hungary
-5%
21:15
Sweden
-4%
21:15
Japan
-12%
21:15
Russia
-7%
19:45
Canada
-3%
20:15
Netherlands
-6%
21:15
Romania
-12%
20:00
Finland
-12%
17:30
Poland
-5%
21:15
South Korea
-4%
20:15
Cuba
-3%
19:00
Bulgaria
-6%
21:15
Switzerland
-10%
18:15
Denmark
-2%
21:15
Spain
-8%
18:15
Norway
-2%
21:15
Belgium
-5%
21:15
Brazil
-3%
18:15
Czech Republic
-10%
18:00
Slovakia
-11%
20:15
Ukraine
-2%
20:45
New Zealand
-9%
21:15
Greece
-11%
18:00
Additionally, the world map below highlights the countries that experienced notable Internet traffic impacts during the opening ceremony.
(Source: Cloudflare; created with Datawrapper)
Outside Europe, the countries with the most substantial drops were New Zealand (-9%), Uzbekistan (-12%), Argentina (-13%), and Mongolia -(20%), all experiencing greater declines than those in Europe.
Significant moments at the games: from Simone Biles to Olympic records
Below, we highlight specific Olympic events affecting Internet traffic, starting from the first full competition day on Saturday, July 27, 2024.
United States: The artistic gymnastics competition featuring four-time Olympic gold medalist Simone Biles notably impacted US Internet traffic more than the opening ceremony. On July 26-28, traffic dipped most significantly during Biles’ events. At 10:00 UTC, concurrent with her beam routine, traffic was already 4% lower than the previous week. It dropped by 6% at 10:45 UTC during her floor and vault routines.
France: French swimmer Léon Marchand’s gold medal and Olympic record-setting performance in the men’s 400-meter individual medley on July 28 had the most significant impact in the host nation. Traffic fell by 17% at 18:30 UTC during his event. However, as we noted above, the opening ceremony drove a bigger drop in traffic.
Australia: During Mollie O’Callaghan’s victory in the women’s 200m freestyle on July 29, at around 20:00 UTC, Australian traffic was 5% lower than the previous week This was larger than during the opening ceremony, which saw a 2% drop.
South Korea: The Korean women’s archery team’s gold medal win on July 28 at 15:30 UTC led to an 8% drop in traffic, the most significant decrease noted in the country from July 26 to July 29.
Brazil: Traffic in Brazil was15% lower than the previous week on July 27 at around 19:30 UTC, surpassing the opening ceremony’s impact. This occurred as Brazilian swimmers Guilherme Costa and Maria Fernanda Costa competed in the men’s and women’s 400 m freestyle events.
DNS trends to official Olympic websites by country
On July 22, before the Olympics started, we reported on the heightened interest in official Olympic websites based on request data from our 1.1.1.1 DNS resolver. We noted France’s dominance with 24% of DNS traffic to official Olympic websites, followed by the UK (20%) and the US (17%). However, the start of the Olympics marked a shift, with the US taking the lead.
On the first full day of competitions, July 27, the US led with 16% of all DNS request traffic to official Olympic sites. This change indicates a broader spread of interest across countries during the Olympics. A dynamic version of the map below is available in our Paris 2024 Olympics report.
Here are the top 10 countries with the highest shares of DNS request traffic for the first full day of competitions, July 27, to Olympic sites (percentages rounded):
United States: 16%
Germany: 12%
France: 9%
Vietnam: 9%
Brazil: 5%
Australia: 5%
United Kingdom: 4%
Netherlands: 4%
Canada: 3%
South Africa: 2%
Growth in interest as the Olympics drew closer
Global daily DNS request traffic to official Olympic websites began climbing to the highest levels seen year to date starting on July 23, showing a steady increase. It peaked on July 28, the second full day of events, with a fivefold (509%) increase from the previous week. On the opening ceremony day, traffic was already 110% higher than the previous week.
Country-specific peaks included the US, where traffic to Olympic sites surged 719% on July 28, coinciding with Simone Biles’ first competition day. In France, traffic peaked on the same day with a 391% increase, and in Germany, it skyrocketed by 2300% on July 27.
The evolving DNS ranking of Olympic site traffic by country reveals that from July 19, the US overtook France. Also, Germany ascended to the #2 spot on July 27, the first full day of competitions, while Australia climbed to #4 on July 28, and Canada’s peak day was also July 28.
Railway attacks on opening ceremony day cause surge in traffic
The opening ceremony day, July 26, was also disrupted by railway arson attacks in France, affecting the 800,000 passengers on the high-speed railway system. At 10:00 UTC, there was a significant surge in DNS traffic to public transportation websites, including high-speed railway services. Traffic spiked by 2000% compared to the previous week as users accessed websites to check updates.
DDoS attacks: always around
As we’ve observed with elections in 2024, including the French elections, political parties are not the only targets of DDoS (Distributed Denial of Service) attacks during significant events. While we haven’t seen any coordinated flow of major DDoS attacks targeting services potentially used during the Olympics in France, we have observed a few incidents.
A generally used French government website was targeted by a DDoS attack on July 29, 2024, lasting nine minutes and peaked at 207,000 requests per second at 20:34 UTC.
Before the Olympics began, a national transportation website was also targeted by a smaller DDoS attack, lasting only a couple of minutes and peaking at 10,000 requests per second on July 21 at 10:20 UTC.
As highlighted in our Q2 DDoS report, most DDoS attacks are short-lived, as exemplified by the two mentioned attacks. Also, 81% of HTTP DDoS attacks peak at under 50,000 requests per second (rps), and only 7% reach between 100,000 and 250,000 rps. While a 10,000 rps attack might seem minor to Cloudflare, it can be devastating for websites not equipped to handle such high levels of traffic.
“Olympics” and “Paris 2024” emails on the rise
From another cybersecurity perspective, major events often attract phishing and spam, and the Olympics are no exception. From January 2024 through late July, Cloudflare’s Cloud Email Security service processed over a million emails containing “Olympics” or “Paris 2024” in the subject. During the week of July 22-28, coinciding with the first few days of the Olympics, there was a 304% increase in such emails compared to the previous week and a staggering 3111% increase compared to the busiest week in January.
Regarding unwanted messages, spam accounted for 1.5% of all emails with “Olympics” or “Paris 2024” in the subject, while malicious emails made up 0.1% since January 2024. This means that in a sample of 1000 emails, roughly 15 would be spam and 1 would be malicious. The peak for malicious Olympic-related emails occurred the week of May 6, with 0.6% classified as malicious. Although there was a decline after this peak, rates increased slightly in July, reaching 0.4% on July 8. Despite the surge in volume during the week of July 22, only 0.05% of emails were malicious.
That same week, when the Olympics started, also saw an increase in spam emails to over 2%, the highest since the 7% peak the week of June 24.
Conclusion
The Paris 2024 Olympics started on July 26, with a clear impact on Internet traffic in different countries, most notably in France, the host nation. The significant traffic drops during key moments of the opening ceremony, and the reactive spikes following major events highlight the ever-present interplay between physical events and the way humans interact with the online world. Not many events take the focus away from the Internet, and in this case, into TV broadcast.
We’ve also observed how the interest in official Olympic websites surged, with clear increases in DNS traffic after the event started, in different countries, with the US ultimately taking the gold.
Regarding the July 29, 2024 sabotage of French fiber optic cables, we did not observe any notable disruptions of Internet traffic in France or its cities during the day.
As the games continue, we will maintain a Paris 2024 Olympics report on Cloudflare Radar, updating it as significant Internet trends related to the event emerge.
The 2024 Summer Olympics, or Paris 2024, is set from July 26 to August 11 in France. The opening ceremony, scheduled for Friday, July 26 at 17:30, will take place for the first time not in a stadium but in the open space of the Jardins du Trocadéro by the Seine River in Paris. We’ll monitor relevant Internet insights throughout the event, but here we analyze some pre-event trends, from the popularity of Olympic websites by country to the increase in Olympics-related spam and malicious emails.
This year’s Olympics will host 329 events across 32 sports, featuring the debut of breakdancing as an Olympic event and the return of skateboarding, sport climbing, and surfing from 2020. Similar to our 2024 elections coverage, we will maintain a Paris 2024 Olympics report on Cloudflare Radar, updating it as significant Internet trends related to the event emerge.
From our 1.1.1.1 resolver, DNS trends show heightened interest in the Olympics, especially from France. 24% of DNS requests for official Olympic-related websites came from the host country, followed by the United Kingdom and the United States, with 20% and 17% respectively.
Here’s the breakdown of countries responsible for at least 1% of 1.1.1.1. traffic for Olympic sites (percentages rounded):
France: 24%
United Kingdom: 20%
United States: 17%
Brazil: 5%
Germany: 4%
Russia: 3%
Australia: 2%
Japan: 2%
India: 2%
Spain: 1%
Ireland: 1%
Canada: 1%
South Africa: 1%
Netherlands: 1%
Italy: 1%
Days with the highest “Olympic” spikes
Analyzing the evolution of DNS traffic to official Olympic websites since January 2024, we’ve noted multiple spikes associated with specific Olympic events or ticket sales. The following ranking offers a global perspective via our 1.1.1.1 resolver, illustrating that as the event draws near and Paris readies itself, more recent dates are emerging prominently in the data.
Top 5 days with higher DNS traffic to Olympic official sites in 2024:
January 31: Eve of the 2024 Winter Youth Olympics closing ceremony in Gangwon, South Korea.
April 17: Over 250,000 new tickets for Olympic Games Paris 2024 went on sale – one of the last opportunities to get tickets to the main events.
January 19: Opening ceremony of the 2024 Winter Youth Olympics (South Korea).
June 26: One month before the opening ceremony; the Paris 2024 Main Operations Center starts full games operation; in Paris, areas like the Champ-de-Mars became full occupied by the Olympics; in the US, tickets for NBC’s Opening Ceremony coverage for the Paris 2024 in IMAX theaters went on sale.
July 1: Preparations in Paris with street and bridges closures and road signs added indicating fast track routes for Olympic related vehicles.
April 10 spikes in Germany, Russia and the US
On April 10, 2024, DNS traffic spikes were observed not just in France but also notably in Germany, Russia, and the US, among others. Despite France leading in overall DNS traffic to Olympic sites since January, as seen on the world map above, this particular day saw the largest spikes originating from other countries. These spikes were most prominent from Germany, Russia, the US, the UK, France, Brazil, and Australia, in that order.
What caused these spikes? Several press conferences related to the Olympics took place that day. One major announcement, covered globally, declared that for the first time, the Olympics would offer prize money, with track and field gold medalists receiving $50,000. The following chart illustrates the spike in DNS traffic in these countries on that day.
France’s trends: interest in tickets comes first
In France, the host nation, ticket sale days significantly influenced DNS traffic to official Olympic websites. The most obvious spike occurred on February 8, 2024, marking the start of the first phase of ticket sales for 2024, called the “Paris 2024 official ticketing website surprise releases.” On that day, daily DNS traffic was double that of the previous week. A significant surge was also observed at 10:00 local time, coinciding with the ticket release, which saw an hourly DNS traffic increase of 398% compared to the previous week.
The week of March 3, 2024, saw the highest DNS traffic to Olympic-related sites in France so far. The most significant increase occurred on March 4, the day the “Athletics Special” ticket sales began for events at the Stade de France, which also coincided with the unveiling of the Olympic poster. On this day, daily DNS traffic rose by 45% compared to the previous week. Other notable periods included the weeks of May 12 and May 19, when the Olympic torch arrived in France and started its journey through various cities. April 14 also marked a critical day, offering one of the last chances to purchase 250,000 tickets for major events.
“Olympics” and “Paris 2024” emails on the rise
From a cybersecurity perspective, as major events often attract phishing and spam, we’ve analyzed email trends related to the Olympics—recently we did the same for the Biden vs Trump US presidential debate. From January 2024 up to late-July, Cloudflare’s Cloud Email Security service processed well over half a million emails containing “Olympics” or “Paris 2024” in the subject. The week of July 15 saw the highest number of such emails, marking a 694% increase compared to the busiest week in January.
Regarding unwanted messages, spam accounted for 1.5% of all emails with “Olympics” or “Paris 2024” in the subject, while malicious emails made up 0.2%. This means that in a sample of 1000 emails, roughly 15 would be spam and about 2 would be malicious. The week with the highest percentage of malicious Olympic-related emails was May 6, with 0.6% classified as malicious. Declining after that peak, it ticked back up in July, to 0.4% on July 8.
Furthermore, the week of June 24 witnessed the highest proportion of spam emails for the year so far, at 7% of all emails.
As the Olympics opening ceremony approaches, we expect the volume of related emails, and the proportion of malicious and spam emails, to increase. We’ll provide an update of the first days of the Olympics next week.
Conclusion: “Citius, Altius, Fortius” *
As the world turns its eyes to Paris for the 2024 Summer Olympics, our latest analysis provides a snapshot of the enthusiasm surrounding the games, with France, the host nation, clearly leading in terms of DNS traffic to official Olympic websites, followed by the UK, the US, and Australia.
With the games about to start, the best is yet to come, with the Olympics bringing over three hundred events in 32 sports to people all around the world.
* “Citius, Altius, Fortius”—Latin for “Faster, Higher, Stronger.” This motto was proposed by Pierre de Coubertin, a French historian and the “father” of the modern Olympic Games, upon the creation of the International Olympic Committee in 1894.
Internet traffic typically mirrors human behavior, with significant fluctuations during large political events. This comes during a time when the United States is in election mode, as political campaigns are in full swing and candidates for various offices, primaries and caucuses make their case to voters and debates are being held. This week, the Republican National Convention was hosted in Milwaukee, Wisconsin from July 15 to 18, 2024. We examined traffic shifts and cyberattacks since June 2024 to see how these events have impacted the Internet.
Attacks on political related websites
Cyberattacks are a constant threat, and aren’t necessarily driven by elections. With that said, notable trends can often be observed, and we’ve seen before how specific geopolitical events can trigger online attacks. For example, we saw cyberattacks at the start of the war in Ukraine to more recently in the Netherlands, when the June 2024 European elections coincided with cyberattacks on Dutch political-related websites that lasted two days — June 5th and 6th. The main DDoS (Distributed Denial of Service attack) attack on June 5, the day before the Dutch election, reached 73,000 requests per second (rps).
Shifting our focus to the United States in particular, in the weeks since April 2024, we’ve seen several DDoS attacks targeting both federal and state government and political-related websites in the United States. In recent days Cloudflare has also blocked DDoS attacks targeting two political-related websites.
One of those is related to a political campaign, represented by the yellow line on the chart below. The first spike was a DDoS attack on July 2, 2024, peaking at 56,000 rps and lasting around 10 minutes. The same political-related site was attacked later on July 14, with a 34,000 rps peak, lasting four minutes.
The other political-related site under attack, in green on the previous chart, is a think tank website that does policy advocacy related to presidential politics. It was already attacked before, around the time of the Biden vs Trump debate, as we’ve published at the time in a related blog post. The main attack was on July 11, with a 137,000 rps peak, lasting a few minutes, and was repeated, with slightly lower intensity, a few hours later on July 12.
As we’ve seen in our recent DDoS report, the vast majority of DDoS attacks are short. This emphasizes the need for automated, in-line detection and mitigation systems. Ten minutes are hardly enough time for a human to respond to an alert, analyze the traffic, and apply manual mitigations.
Trump assassination attempt impact
The attempted assassination of former President Trump at a campaign rally near Butler, Pennsylvania precipitated an increase in Internet traffic within the United States, particularly to news-related media outlets. As news broke of shots fired at a Trump rally, injuring the former president, Internet traffic in the United States (in bytes) increased around 22:30 – 23:00 UTC (18:30-19:00 EST) by 10% to 12%.
HTTP requests in the United States saw up to an 8% increase on July 13th compared to the previous week.
At the same time, DNS traffic to TV news sites, via our 1.1.1.1 resolver, surged by as much as 215%, and to general news sites by 141%.
Republican National Convention
The Republican National Convention is an important political event as delegates of the United States Republican Party choose the party’s nominees for president and vice president in the 2024 United States presidential election. Over the four-day event, convention delegates formally nominate the party’s presidential and vice presidential candidates and adopt the party’s platform, which outlines its policies and positions on various issues. The convention features speeches from prominent party members, including the nominees, party leaders, and other influential figures.
This year’s convention was held in Milwaukee, Wisconsin. During this time, we didn’t identify any noticeable traffic spikes from Milwaukee or from Wisconsin in general.
Compared to the previous week, there was an increase in DNS traffic to Republican political party and fundraising websites. On July 18th, the last day of the convention, we saw two considerable increases in hourly traffic compared to a week prior. The first at 14:00 EDT, an increase of 268% in traffic to these sites. The second, at 23:00 EDT with another increase at 266%. The daily aggregation on this day was an increase of 90.48% compared to daily traffic aggregations in the previous week.
For DNS traffic during the convention for TV news channels, we see steady traffic numbers with the highest peaking days before the convention on July 14, then during the late hours of July 15th.
For political news websites covering the RNC, traffic numbers tend to decrease slightly as the event progresses.
We identified an attack against a think-tank based in Washington D.C. that does policy advocacy related to presidential politics. The attack itself lasted around 3 minutes, from July 18th 13:18 to 13:22 exclusive (EDT) with a total of 3.12 million DDoS requests mitigated. The attack peaked at around 30.33k rps.
We see that major political events may not always cause significant shifts in Internet traffic. Our data indicates increases in traffic primarily to news and media organizations from July 13th onward. When it comes to cyber attacks, a majority of activity we see targets political campaigns and policy organizations.
If you want to follow more trends and insights about the Internet and elections in particular, you can check Cloudflare Radar, and more specifically our new 2024 Elections Insights report, which will be updated as elections take place throughout the year.
Cloudflare’s network spans more than 320 cities in over 120 countries, where we interconnect with over 13,000 network providers in order to provide a broad range of services to millions of customers. The breadth of both our network and our customer base provides us with a unique perspective on Internet resilience, enabling us to observe the impact of Internet disruptions. Thanks to Cloudflare Radar functionality released earlier this year, we can explore the impact from a routing perspective, as well as a traffic perspective, at both a network and location level.
As we have seen in previous years, nationwide exams take place across several MENA countries in the second quarter, and with them come government directed Internet shutdowns. Cable cuts, both terrestrial and submarine, caused Internet outages across a number of countries, with the ACE submarine cable being a particular source of problems. Maintenance, power outages, and technical problems also disrupted Internet connectivity, as did unknown issues. And as we have frequently seen in the two-plus years since the conflict began, Internet connectivity in Ukraine suffers as a result of Russian attacks.
As we have noted in the past, this post is intended as a summary overview of observed disruptions, and is not an exhaustive or complete list of issues that have occurred during the quarter.
Government directed
Syria, Algeria, Iraq
Each spring, governments in several countries in the Middle East and North Africa (MENA) region order local telecommunications providers to shut down or disrupt Internet connectivity across the country in an effort to prevent students from cheating on national secondary and high school exams. These shutdowns/disruptions generally occur for several hours per day over a multi-week period. We covered such events in 2023, 2022, and 2021, as they occurred in locations including Syria, Sudan, Algeria, and Iraq.
In June, we published Exam-ining recent Internet shutdowns in Syria, Iraq, and Algeria, which examined the daily Internet shutdowns that took place in Iraq and Syria, as well as the two multi-hour daily disruptions in Algeria, which appeared to be pursuing a content blocking strategy, rather than a full nationwide shutdown. The post examined the impact that these shutdowns have on Internet traffic, and also analyzed routing information and traffic from other Cloudflare services in an effort to better understand how these shutdowns are being implemented.
In addition to the shutdowns covered in the previously referenced blog post, Iraq implemented a second round of shutdowns that started on June 23, and ran through at least July 14. Some of these shutdowns impacted the same set of networks seen in the first round, and some impacted networks in the autonomous Kurdistan region in the north.
Both sets of shutdowns reviewed above appeared to have followed the same approach as the first round covered in the earlier blog post.
Kenya, Burundi, Uganda, Rwanda, Tanzania
Concerns over a potential Internet shutdown during planned protests against tax increases proposed in “Finance Bill 2024” by the Kenyan government led to the publication of a joint statement signed by multiple organizations. The statement strongly urged the Kenyan government to refrain from enforcing any
Internet shutdowns or information controls, and highlighted the “disastrous economic effects” such a move could have. In response, the Communications Authority of Kenya issued a press release stating that “For the avoidance of doubt, the Authority has no intention whatsoever to shut down Internet traffic or interfere with the quality of connectivity. Such actions would be a betrayal of the Constitution as a whole, the freedom of expression in particular and our own ethos.”
As protests escalated on June 25, Internet traffic in Kenya dropped at 16:30 local time (13:30 UTC). Initially, this outage was thought to be due to issues with one or more undersea cables that provide international connectivity to the country, with the potential cause supported by social media posts from Safaricom and Airtel.
Similar concurrent drops in Internet traffic were observed in Burundi, Uganda, Rwanda, and Tanzania, as shown below. Issues with submarine cables connected to one country can impact Internet connectivity in other countries if there is a dependency on that country/cable for upstream Internet connectivity. As such, the observed disruptions in those four countries were not that unusual. To that end, a (subsequently deleted) post on X from MTN Uganda noted: “Our esteemed customers, We are experiencing a degraded service on all our internet services due to an outage caused by our connectivity supply through Kenya. Our technical teams and partners are working jointly to resolve the issue in the shortest time possible. In the interim, we kindly advise our customers to use *165# to access Mobile Money and other app based services. Thank you.“
However, other participants in the Internet infrastructure community in Africa called the undersea cable outage explanation into question. Kyle Spencer, Executive Director of the Uganda Internet eXchange Point, posted on X that “I am told the Kenyan government ordered sea cable landing stations to disconnect circuits.” Ben Roberts, Group CTIO at Liquid Intelligent Technologies (a pan-African network infrastructure provider), posted “No cables are damaged this week.” In addition, outages on undersea cables are rarely, if ever, resolved in a matter of hours, as this disruption was – they frequently last for days or weeks.
On June 26, Safaricom’s CEO claimed “This outage was occasioned by reduced bandwidth on some cables that carry Internet traffic”, contradicting the company’s original claim. No additional information was forthcoming from Airtel or the Communications Authority of Kenya, but as noted above, some within the industry believe that the disruption that impacted connectivity in Kenya, Burundi, Uganda, Rwanda, and Tanzania was directed by the government of Kenya, and was not caused by submarine cable outages.
Cable cuts
Haiti
At 17:36 local time (21:36 UTC) on April 28, Digicel Haiti posted an “important note” on X that stated in part (translated) “On April 27, 2024, the company suffered several attacks on its international optical infrastructure in the Drouya area on National Road #1. The optical fiber was damaged by the impact of cartridges after the armed clashes in the area for a few days. It affected several services such as internet (data), SMS, MonCash and international calling. For now, we are happy to inform the population that all services are restored to 100%.” The graph below shows the impact of the fiber damage, with AS27653 (Digicel Haiti) suffering an Internet outage lasting nearly 24 hours, from around 17:30 local time (21:30 UTC) on April 27 through approximately 16:00 local time (20:00 UTC) on April 28, after which traffic quickly recovered.
Then on May 3, The Director General of Digicel Haiti posted on X that (translated) “Digicel is informing the general public that it suffered two more damages to its international fiber infrastructure at 2am this morning. We have restored Moncash services, SMS, and Fiber Optic connections. Our crews are already on their way to address the apparent landslide in the Canaan area.” The disruption caused by this fiber damage lasted for approximately eight hours, between 02:15 – 10:30 local time (06:15 – 14:30 UTC), and as seen in the graph below, appeared to have a nominal impact on traffic.
On Sunday, May 12, issues with the EASSy and Seacom submarine cables again disrupted connectivity to East Africa, impacting a number of countries previously affected by a set of cable cuts that occurred nearly three months earlier. Insight into these earlier cable cuts and the initial impact of May’s cable damage was covered in our East African Internet connectivity again impacted by submarine cable cuts blog post.
Traffic levels across a number of the impacted countries dropped just before 11:00 local time (08:00 UTC). The magnitude of the initial impact varied by country, with traffic initially dropping by 10-25% in Kenya, Uganda, Madagascar, and Mozambique, while traffic in Rwanda, Malawi, and Tanzania dropped by one-third or more than compared to the previous week. The overall impact was most significant in Tanzania, Madagascar, and Rwanda, as seen in the graphs below. Traffic returned to expected levels at various times over the following week, ranging from a day and a half later (May 13) in Kenya to a week later (May 19) in Rwanda.
Repairs to the EASSy and Seacom cables were completed on May 31. Repairs to the cables damaged in February were ongoing as of July 9, as their location in a war zone complicates repair efforts.
Chad
A reported fiber optic cable cut in Cameroon disrupted Internet connectivity for customers of Moov Africa TChad on May 25. The outage lasted three hours, between 15:15 -18:15 local time (14:15 – 17:15 UTC), with the impact visible at a country level as well. Routing was disrupted too, as the number of IPv4 /24 prefixes (256 IPv4 addresses) announced by Moov Africa Tchad fell from eight to three during the disruption.
The event was similar to one that occurred on January 10, when Moov Africa Tchad and country-level traffic was disrupted for over 12 hours “due to a cut in the optical fiber coming from Cameroon through which Chad has access to the Internet”. During that event, significant volatility was also observed from a routing perspective, as the volume of announced IPv4 address space shifted frequently at a network and country level during the disruption. As we noted last quarter, as a landlocked country, Chad is dependent on terrestrial Internet connections to/through neighboring countries, and the AfTerFibre cable map illustrates Chad’s reliance on limited cable paths through Cameroon and Sudan.
Gambia, Mauritania, Senegal
A reported “network interruption” on the Africa Coast to Europe (ACE) submarine cable disrupted traffic across networks in the Gambia, Mauritania, and Senegal on June 5. AS25250 (Gamtel), AS29544 (Mauritel), and AS37649 (Free/Tigo) all saw traffic drop around 23:00 local time (23:00 UTC). As seen in the graphs below, the outage lasted for nearly 11 hours, with traffic recovering just 10:00 local time on June 6 (10:00 UTC). Mauritel saw a near complete outage, while Gamtel and Free/Tigo saw less severe impacts, possibly because they were able to shift traffic to back up links.
Maintenance
Guinea, Gambia, Sierra Leone, Liberia
Above, we discussed an unexpected network interruption on the ACE submarine cable that caused outages across multiple countries on June 5. However, two months earlier, a planned outage for repair work on the cable also disrupted connectivity across multiple African countries. A communiqúe issued by the Ministry of Posts, Telecommunications and the Digital Economy in Guinea noted in part (translated) “…the ACE (Africa Coast to Europe) network will undergo a planned outage on April 8, 2024, between midnight and 2:00 a.m. morning in the following countries: Guinea, Senegal, Gambia, Sierra Leone and Liberia. This total outage of approximately 2 hours will affect Internet traffic and international calls.”
The graphs below show the impact to traffic in the listed countries for the planned two-hour repair window, though it appears that traffic did not return fully to expected levels after the repair window concluded – it is unclear why it remained slightly depressed. In addition, despite being listed as one of the impacted countries, no impact to traffic was observed in Senegal.
Guinea
Rounding out a trifecta of entries about the ACE submarine cable, planned maintenance work on the cable by GUILAB reportedly caused a multi-hour outage at AS37461 (Orange Guinea) and at a country level as well, lasting from 12:15 – 15:45 local time (12:15 – 15:45 UTC). (GUILAB is the company in charge of managing the capacity allocated to Guinea on the ACE submarine cable.) The maintenance work was reported by Orange Guinea in two X posts (1, 2), although these posts were subsequently deleted.
Power outage
Kenya
At 18:30 local time (15:30 UTC) on May 2, Kenya Power posted a “Power Outage Alert” on X that stated “At 5:40 PM (EAT) today, Thursday, 2nd May 2024, we experienced a system disturbance on the grid, resulting in power supply disruption in most parts of the country.” The graph below shows the resultant impact on Internet connectivity in the country, with traffic dropping sharply between 17:30 – 17:45 local time (14:30 – 14:45 UTC). The drop in traffic lasted until approximately 21:30 local time (18:30 UTC), the same time that Kenya Power posted a “Power Supply Restoration” notice on X, highlighting the restoration of power to parts of the country. Although the post-outage spike seen in the graph would suggest pent-up demand for online content, a longer-term view of Kenya’s Internet traffic shows traffic peaks at the same time (22:00 local time, 19:00 UTC) during the preceding two days as well.
Ecuador
A nationwide power outage in Ecuador on June 19 impacted hospitals, homes, and the subway, in addition to causing a major disruption to Internet connectivity. The graph below shows Ecuador’s Internet traffic dropping sharply just after 15:00 local time (20:00 UTC). A post on X from Public Works Minister Roberto Luque explained (translated) “The immediate report that we received from CENACE is that there is a failure in the transmission line that caused a cascade disconnection, so there is no energy service on a national scale.” A subsequent post pointed at a lack of investment in the underlying systems, and noted that as of 18:41 pm local time (23:41 UTC), “95% of the energy has already been restored”. After the initial sharp drop, traffic began to recover fairly quickly, and was effectively back to expected levels by the stated time.
Albania, Bosnia, Montenegro
A sudden increase in power consumption related to increased usage due to high temperatures, as well electrical systems being impacted by the heat, caused a widespread power outage across Montenegro, Bosnia, and Montenegro on June 21. The outage reportedly originated in Montenegro after a 400-kilowatt transmission line exploded. While power outages are generally more localized to a single country, or region within a country, power distribution systems are linked across Balkan countries as part of the Trans-Balkan Electricity Corridor.
Published reports (MSN, Reuters) noted that electrical networks went down 12:00 – 13:00 local time (10:00 – 11:00 UTC), and that electricity suppliers in the impacted countries started restoring power by mid-afternoon, and had it largely restored by the evening. The graphs below show traffic from Albania, Bosnia, and Montenegro starting to drop around 12:00 local time (10:00 UTC), reaching its nadir in Albania and Bosnia at 12:30 local time (10:30 UTC) and at 13:00 local time (11:00 UTC) in Montenegro. Traffic recovered gradually over the next several hours as power was restored, returning to expected levels by 15:30 local time (13:30 UTC).
Croatia was reportedly impacted by the power outage as well, but no adverse impact to traffic at a country level is visible during the timeframe that connectivity in the other countries was disrupted.
Military action
Ukraine
During the two-plus years of the Russia-Ukraine conflict, Ukraine’s power grid has been a frequent target for Russian air attacks. When damage to Ukraine’s electrical power infrastructure occurs as a result of these attacks, Internet connectivity is also disrupted. Attacks on May 21 caused power outages across a number of areas in Ukraine. The most significant impact was in Sumy, where traffic dropped as low as 82% below the previous week at 00:00 on May 22 local time (21:00 UTC). As the graphs below illustrate, traffic was also lower than the previous week for several hours in Kyiv, Kharkiv, and Vinnytsia, with traffic returning to expected levels by around 08:00 local time (05:00 UTC) on May 22.
\
Technical problems
Malaysia
As we’ve covered in previous quarterly posts, Internet outages and disruptions aren’t always due to significant wide-scale events like severe weather, power outages, or cable cuts. Sometimes more mundane technical issues can cause problems when users try to access the Internet. One example of this occurred on April 15 in Malaysia, when customers of Time Internet experienced a network outage for nearly two hours. The company explained the reason for the outage in a contrite post on their Facebook page, stating in part “This Internet service outage was by far the worst in our history – affecting approximately 40% of our customers. … At 5.38pm today, both our primary and secondary Secure DNS servers became unreachable. This means that any browser or service requiring a DNS address resolution was not able to reach its intended site.” Because subscribers could not reach Time Internet’s DNS resolvers, they were unable to resolve hostnames for Internet services, sites, and applications, including those delivered by Cloudflare. This resulted in the drop in traffic seen in the graph below, which started just after 17:00 local time (05:00 UTC), and began to recover approximately an hour later. The company did not provide any additional information on what caused the DNS servers to fail.
Nepal
In Nepal, a number of local Internet service providers including AS45650 (Vianet) and AS139922 (Dishhome) rely on Indian provider Bharti Airtel for upstream connectivity, enabling them to reach the rest of the Internet. A published report underscores the reliance, noting “Nepali ISPs buy 70 percent of their internet from Airtel.”
On April 25, these ISPs warned that their services could be interrupted because the Nepali government had not provided them with foreign exchange services that would enable them to pay bandwidth vendors such as Airtel, whom they reportedly owed USD $30 million to. On May 1, Airtel informed the delinquent Nepali providers that Internet services may be interrupted at any time due to the overdue payment, and on May 2, Airtel took that step. The graphs below show Vianet’s traffic dropping to near zero at 16:15 local time (10:30 UTC), recovering to expected levels six hours later. An hour later, at 17:15 local time (11:30 UTC), Dishhome’s traffic dropped significantly, though not as severely as Vianet’s. Dishhome’s traffic also recovered approximately six hours later.
A month later, on June 3, AS45650 (Vianet) and AS17501 (Worldlink) in Nepal experienced Internet disruptions that were reportedly caused by routing issues on Bharti Airtel’s network. On Worldlink, a drop in traffic occurred between 12:15 – 14:00 local time (06:30 – 08:15 UTC), while on Vianet, the loss of traffic took place between 12:15 – 13:15 local time (06:30 – 07:30 local time).
Unknown
Most of the Internet disruptions covered in this blog post series have a known root cause, whether admitted/stated by the impacted provider(s) or closely associated with a real world event (severe weather, power outage, etc.) However, other disruptions are observed and even publicized by the impacted provider, but no underlying reason for the outage is ever made public.
Malaysia
On May 21, CelcomDigi (AS10030)posted on X that it was experiencing an outage on its network, and that it was working to resolve the issue as soon as possible. However. just 12 minutes later, it published a second post stating that it had fully restored Celcom Internet service. These posts were made at 21:35 and 21:47 local time (13:35 and 13:47) respectively. However, as the graph below shows, traffic volumes had returned to expected levels over an hour earlier, as the observed Internet disruption on Celcom’s network lasted between 18:00 – 20:15 local time (10:00 – 12:15 UTC). (Note that the second disruption shown in the graph below was due to an internal Cloudflare data pipeline issue, and not any sort of problem with Celcom’s network.)
Starlink
SpaceX Starlink’s satellite Internet service is unique in that it has an international subscriber base, so outages on its network have a more wide-reaching impact than issues with an ISP that covers a single country. At 01:59 UTC on May 29, Starlinkshared on X that it was currently experiencing a network outage, and that it was actively implementing a solution. Twenty-eight minutes later, it posted “The network issue has been fully resolved.” This brief outage is visible in the graph below as a slight dip in traffic. However, what is particularly interesting is the spike in traffic to Cloudflare from Starlink’s network following the resolution of the outage. The sharp increase and rapid decline of the traffic curve after service was restored suggests that it may be related to an automated connectivity check of some kind, rather than pent-up user demand for content.
Chad
A near-complete Internet outage was observed in Chad on June 5 between 08:15 – 12:00 local time (07:15 – 11:00 UTC), as seen in the graph below. Routing was also impacted, as the number of IPv4 /24 address blocks (256 IPv4 addresses) announced by network providers in the country dropped by as much as 75% during the outage.
A news item covering the outage noted that only Starlink subscribers retained Internet access during the outage. It also noted that Chad has faced recurring Internet disruptions since 2016, either because of problems with fiber-optic cables, or due to government directed shutdowns in the name of national security. It is unclear what ultimately caused this particular outage.
India
With an estimated subscriber base in excess of over 460 million, any Internet disruption affecting Reliance Jio’s network (AS55836) is going to have a widespread impact across India. On June 18, Reliance Jio experienced two disruptions that occurred between 13:15 – 17:15 local time (07:45 – 11:45 UTC). Each disruption lasted less than an hour, and dropped traffic levels to approximately half of those seen at the same time a week prior. Both mobile and fiber connectivity was affected, and no additional information has been provided by Reliance Jio regarding the root cause of the connectivity issues.
Conclusion
As we become increasingly dependent on reliable Internet connectivity, we must recognize that that connectivity is itself reliant on a complex and interconnected foundation of physical, technical, and political factors. A failure in any one of these foundational components, whether due to a cable cut, power outage, misconfiguration, or government action, can have a significant impact, disrupting Internet connectivity for millions of users, potentially across multiple countries. While the resilience and reliability of the physical and technical components can be improved through redundancy and best practices, political factors have arguably proven to be the hardest to address. However, organizations like AccessNow, through their #KeepItOn campaign, mobilize people, communities, and civil society actors globally to fight against government-directed Internet shutdowns, which can have significant financial consequences.
National team sports unite countries, and football (known as “soccer” in the US) is the world’s most popular sport, boasting approximately 3.5 billion fans globally. The UEFA Euro 2024, running from June 14 to July 14, 2024, significantly impacts Internet traffic across participating European nations. This blog post focuses on the two finalists, Spain and England, and comes after an initial post we published during the first week of the tournament.
Analyzing traffic patterns reveals distinct high-level trends. Spain saw the most significant drops in Internet traffic during games against major teams and former champions such as Italy (the defending champion), Germany, and France. In contrast, England’s games had crucial moments towards the end, leading to the largest traffic reductions in the UK, especially during the knockout stages.
For context, as previously mentioned, football games like the Super Bowl, differ from other events such as elections. When major teams or national squads play, especially in matches that captivate many viewers, Internet traffic often drops. This is particularly true if the game is broadcast on a national TV channel. During such broadcasts, people tend to focus more on their TV sets, relying on the traditional broadcast signal rather than online streaming, especially for games that aren’t behind a paywall. This is a typical scenario when national teams play in Europe.
Semifinals: differences between four countries
Let’s first analyze the impact of the semifinals on the four countries with national teams playing, using UK-related data for England. The following table displays the traffic drop percentages and the times of the largest declines during the Spain vs. France and Netherlands vs. England matches. Note that England is the only one not on Central European Time.
In both Spain and the UK, traffic decreased the most at the end of the game, details of which are provided below. In France and the Netherlands, significant drops of 16% and 27% respectively occurred primarily in the first half.
Country
Drop on traffic
Date / time of biggest drop (local time)
Spain
-19%
Jul 9, 22:45
France
-16%
Jul 9, 21:00
Netherlands
-27%
Jul 10, 21:15
England (UK)
-11%
July 10, 21:45
(Source: Cloudflare; created with Datawrapper)
Traffic in the UK: England’s late goal impact
England’s matches frequently saw crucial moments near the end, leading to the largest dips in UK Internet traffic. This trend was especially pronounced during the knockout phases and after Scotland’s exit from the tournament. England’s tournament opener, a win against Serbia on June 16, experienced the most significant traffic drop at the game’s start – an 8% decrease from the previous week.
UK election debate vs England’s game
The second game, on June 20, against Denmark, ended in a draw and saw a bigger drop in traffic. During the game, traffic in the UK initially dropped 8% compared to the previous week, then fell even further in the second half, by as much as 13%. Following the game, the BBC broadcast a significant live event – the debate between the country’s four major political parties. It started at 20:00 local time, and 15 minutes later, traffic experienced its largest drop of the day: 15%.
The third and final group stage game for England, a draw against Slovenia, saw a 5% drop in Internet traffic during the second half and a 4% drop in the first half. In the round of 16 game against Slovakia on June 30, traffic dipped 9% in the UK towards the end of the second half as Jude Bellingham scored a crucial late goal. During extra time, when Harry Kane scored, traffic decreased further to 10% below the previous week’s level.
Next, during the July 6 quarter-final against Switzerland, traffic in the UK dipped 3% during the game, mostly towards the end of regular time. However, it decreased further by 11% towards the end of extra time and during the penalty shootouts.
The semi-final between England and the Netherlands on July 10, 2024, experienced a noticeable drop in UK traffic – 5% at 20:15, when the first two goals were scored. Traffic decreased further, to 11% below the previous week, at the end of the game as Ollie Watkins scored the winning goal, securing England’s spot in the final.
Spain’s big game traffic impact
Spain was the only team to win all its matches without going to penalties throughout the tournament. The most significant drops in Internet traffic occurred during games against other major teams and previous titleholders like Italy, Germany, and France.
Spain’s first game in the tournament against Croatia on June 15, during dinner time in the country, ended in a decisive 3-0 win. It was accompanied by a significant drop in traffic – 7% in the first half and 9% in the second.
The June 20 match against Italy, featuring two teams with rich histories of European and World titles – and Italy as the defending champion – captured significant attention. Also broadcast on national TV, as the other games were, it led to substantial drops in traffic: a 16% decrease early in the first half, and a 15% drop in the second half, right after halftime, aligning with Calafiori’s goal that secured Spain’s win.
The final group stage game for Spain against Albania on June 24, which was non-decisive with Spain’s advancement already secured, saw a traffic decrease of 6%. Then came the knockout phase. It began with a round of 16 match against Georgia on June 30, where traffic fell by up to 8%, with a more pronounced drop in the first half coinciding with Spain equalizing the game.
The July 5 quarterfinals against host Germany was also a game that matched two football giants, in terms of national team international football titles. The game began with an initial 10% decline in traffic, followed by a 7% drop in the second half, and an 8% drop at the end of extra time, around the time Merino scored the winning goal.
Spain’s semi-final on July 9 saw early goals and a swift turnaround after France’s initial goal. The game started with a 17% drop in traffic compared to the previous week, persisting through the first half. By the end of the second half, as France aggressively sought to score and Spain defended vigorously to avoid extra time, traffic dipped further to a 19% drop. Ultimately, the Spanish squad secured a spot in the final.
Conclusion
The UEFA Euro 2024 has significantly impacted Internet traffic across participating European countries from Cloudflare’s perspective. Games broadcast on national TV drew fans’ attention away from the Internet. Critical moments such as last-minute goals, extra time, or penalty shootouts also led to larger drops in traffic as fans focused more on the game.
Also, distinct patterns have emerged in the finalist countries, Spain and England. For Spain, matches against traditional football powerhouses resulted in noticeable drops in traffic, indicating high viewer engagement during key matches. England’s games also saw significant traffic reductions at critical moments, particularly during the knockout stages.
Welcome to the 18th edition of the Cloudflare DDoS Threat Report. Released quarterly, these reports provide an in-depth analysis of the DDoS threat landscape as observed across the Cloudflare network. This edition focuses on the second quarter of 2024.
With a 280 terabit per second network located across over 230 cities worldwide, serving 19% of all websites, Cloudflare holds a unique vantage point that enables us to provide valuable insights and trends to the broader Internet community.
Key insights for 2024 Q2
Cloudflare recorded a 20% year-over-year increase in DDoS attacks.
1 out of every 25 survey respondents said that DDoS attacks against them were carried out by state-level or state-sponsored threat actors.
Threat actor capabilities reached an all-time high as our automated defenses generated 10 times more fingerprints to counter and mitigate the ultrasophisticated DDoS attacks.
Quick recap – what is a DDoS attack?
Before diving in deeper, let’s recap what a DDoS attack is. Short for Distributed Denial of Service, a DDoS attack is a type of cyber attack designed to take down or disrupt Internet services, such as websites or mobile apps, making them unavailable to users. This is typically achieved by overwhelming the victim’s server with more traffic than it can handle — usually from multiple sources across the Internet, rendering it unable to handle legitimate user traffic.
Diagram of a DDoS attack
To learn more about DDoS attacks and other types of cyber threats, visit our Learning Center, access previous DDoS threat reports on the Cloudflare blog or visit our interactive hub, Cloudflare Radar. There’s also a free API for those interested in investigating these and other Internet trends.
To learn about our report preparation, refer to our Methodologies.
Threat actor sophistication fuels the continued increase in DDoS attacks
In the first half of 2024, we mitigated 8.5 million DDoS attacks: 4.5 million in Q1 and 4 million in Q2. Overall, the number of DDoS attacks in Q2 decreased by 11% quarter-over-quarter, but increased 20% year-over-year.
Distribution of DDoS attacks by types and vectors
For context, in the entire year of 2023, we mitigated 14 million DDoS attacks, and halfway through 2024, we have already mitigated 60% of last year’s figure.
Cloudflare successfully mitigated 10.2 trillion HTTP DDoS requests and 57 petabytes of network-layer DDoS attack traffic, preventing it from reaching our customers’ origin servers.
DDoS attacks stats for 2024 Q2
When we break it down further, those 4 million DDoS attacks were composed of 2.2 million network-layer DDoS attacks and 1.8 million HTTP DDoS attacks. This number of 1.8 million HTTP DDoS attacks has been normalized to compensate for the explosion in sophisticated and randomized HTTP DDoS attacks. Our automated mitigation systems generate real-time fingerprints for DDoS attacks, and due to the randomized nature of these sophisticated attacks, we observed many fingerprints being generated for single attacks. The actual number of fingerprints that was generated was closer to 19 million – over ten times larger than the normalized figure of 1.8 million. The millions of fingerprints that were generated to deal with the randomization stemmed from a few single rules. These rules did their job to stop attacks, but they inflated the numbers, so we excluded them from the calculation.
HTTP DDoS attacks by quarter, with the excluded fingerprints
This ten-fold difference underscores the dramatic change in the threat landscape. The tools and capabilities that allowed threat actors to carry out such randomized and sophisticated attacks were previously associated with capabilities reserved for state-level actors or state-sponsored actors. But, coinciding with the rise of generative AI and autopilot systems that can help actors write better code faster, these capabilities have made their way to the common cyber criminal.
Ransom DDoS attacks
In May 2024, the percentage of attacked Cloudflare customers that reported being threatened by a DDoS attack threat actor, or subjected to a Ransom DDoS attack reached 16% – the highest it’s been in the past 12 months. The quarter started relatively low, at 7% of customers reporting a threat or a ransom attack. That quickly jumped to 16% in May and slightly dipped in June to 14%.
Percentage of customers reporting DDoS threats or ransom extortion (by month)
Overall, ransom DDoS attacks have been increasing quarter over quarter throughout the past year. In Q2 2024, the percentage of customers that reported being threatened or extorted was 12.3%, slightly higher than the previous quarter (10.2%) but similar to the percentage of the year before (also 12.0%).
Percentage of customers reporting DDoS threats or ransom extortion (by quarter)
Threat actors
75% of respondents reported that they did not know who attacked them or why. These respondents are Cloudflare customers that were targeted by HTTP DDoS attacks.
Of the respondents that claim they did know, 59% said it was a competitor who attacked them. Another 21% said the DDoS attack was carried out by a disgruntled customer or user, and another 17% said that the attacks were carried out by state-level or state-sponsored threat actors. The remaining 3% reported it being a self-inflicted DDoS attack.
Percentage of threat actor type reported by Cloudflare customers, excluding unknown attackers and outliers
Top attacked countries and regions
In the second quarter of 2024, China was ranked the most attacked country in the world. This ranking takes into consideration HTTP DDoS attacks, network-layer DDoS attacks, the total volume and the percentage of DDoS attack traffic out of the total traffic, and the graphs show this overall DDoS attack activity per country or region. A longer bar in the chart means more attack activity.
After China, Turkey came in second place, followed by Singapore, Hong Kong, Russia, Brazil, and Thailand. The remaining countries and regions comprising the top 15 most attacked countries are provided in the chart below.
15 most attacked countries and regions in 2024 Q2
Most attacked industries
The Information Technology & Services was ranked as the most targeted industry in the second quarter of 2024. The ranking methodologies that we’ve used here follow the same principles as previously described to distill the total volume and relative attack traffic for both HTTP and network-layer DDoS attacks into one single DDoS attack activity ranking.
The Telecommunications, Services Providers and Carrier sector came in second. Consumer Goods came in third place.
15 most attacked industries in 2024 Q2
When analyzing only the HTTP DDoS attacks, we see a different picture. Gaming and Gambling saw the most attacks in terms of HTTP DDoS attack request volume. The per-region breakdown is provided below.
Top attacked industries by region (HTTP DDoS attacks)
Largest sources of DDoS attacks
Libya was ranked as the largest source of DDoS attacks in the second quarter of 2024. The ranking methodologies that we’ve used here follow the same principles as previously described to distill the total volume and relative attack traffic for both HTTP and network-layer DDoS attacks into one single DDoS attack activity ranking.
Indonesia followed closely in second place, followed by the Netherlands in third.
15 largest sources of DDoS attacks in 2024 Q2
DDoS attack characteristics
Network-layer DDoS attack vectors
Despite a 49% decrease quarter-over-quarter, DNS-based DDoS attacks remain the most common attack vector, with a combined share of 37% for DNS floods and DNS amplification attacks. SYN floods came in second place with a share of 23%, followed by RST floods accounting for a little over 10%. SYN floods and RST floods are both types of TCP-based DDoS attacks. Collectively, all types of TCP-based DDoS attacks accounted for 38% of all network-layer DDoS attacks.
Top attack vectors (network-layer)
HTTP DDoS attack vectors
One of the advantages of operating a large network is that we see a lot of traffic and attacks. This helps us improve our detection and mitigation systems to protect our customers. In the last quarter, half of all HTTP DDoS attacks were mitigated using proprietary heuristics that targeted botnets known to Cloudflare. These heuristics guide our systems on how to generate a real-time fingerprint to match against the attacks.
Another 29% were HTTP DDoS attacks that used fake user agents, impersonated browsers, or were from headless browsers. An additional 13% had suspicious HTTP attributes which triggered our automated system, and 7% were marked as generic floods. One thing to note is that these attack vectors, or attack groups, are not necessarily exclusive. For example, known botnets also impersonate browsers and have suspicious HTTP attributes, but this breakdown is our initial attempt to categorize the HTTP DDoS attacks.
Top attack vectors (HTTP)
HTTP versions used in DDoS attacks
In Q2, around half of all web traffic used HTTP/2, 29% used HTTP/1.1, an additional fifth used HTTP/3, nearly 0.62% used HTTP/1.0, and 0.01% for HTTP/1.2.
Distribution of web traffic by HTTP version
HTTP DDoS attacks follow a similar pattern in terms of version adoption, albeit a larger bias towards HTTP/2. 76% of HTTP DDoS attack traffic was over the HTTP/2 version and nearly 22% over HTTP/1.1. HTTP/3, on the other hand, saw a much smaller usage. Only 0.86% of HTTP DDoS attack traffic were over HTTP/3 — as opposed to its much broader adoption of 20% by all web traffic.
Distribution of HTTP DDoS attack traffic by HTTP version
DDoS attack duration
The vast majority of DDoS attacks are short. Over 57% of HTTP DDoS attacks and 88% of network-layer DDoS attacks end within 10 minutes or less. This emphasizes the need for automated, in-line detection and mitigation systems. Ten minutes are hardly enough time for a human to respond to an alert, analyze the traffic, and apply manual mitigations.
On the other side of the graphs, we can see that approximately a quarter of HTTP DDoS attacks last over an hour, and almost a fifth last more than a day. On the network layer, longer attacks are significantly less common. Only 1% of network-layer DDoS attacks last more than 3 hours.
HTTP DDoS attacks: distribution by durationNetwork-layer DDoS attacks: distribution by duration
DDoS attack size
Most DDoS attacks are relatively small. Over 95% of network-layer DDoS attacks stay below 500 megabits per second, and 86% stay below 50,000 packets per second.
Distribution of network-layer DDoS attacks by bit rateDistribution of network-layer DDoS attacks by packet rate
Similarly, 81% of HTTP DDoS attacks stay below 50,000 requests per second. Although these rates are small on Cloudflare’s scale, they can still be devastating for unprotected websites unaccustomed to such traffic levels.
Distribution of HTTP DDoS attacks by request rate
Despite the majority of attacks being small, the number of larger volumetric attacks has increased. One out of every 100 network-layer DDoS attacks exceed 1 million packets per second (pps), and two out of every 100 exceed 500 gigabits per second. On layer 7, four out of every 1,000 HTTP DDoS attacks exceed 1 million requests per second.
Key takeaways
The majority of DDoS attacks are small and quick. However, even these attacks can disrupt online services that do not follow best practices for DDoS defense.
Furthermore, threat actor sophistication is increasing, perhaps due to the availability of Generative AI and developer copilot tools, resulting in attack code that delivers DDoS attacks that are harder to defend against. Even prior to the rise in attack sophistication, many organizations struggled to defend against these threats on their own. But they don’t need to. Cloudflare is here to help. We invest significant resources – so you don’t have to – to ensure our automated defenses, along with the entire portfolio of Cloudflare security products, to protect against existing and emerging threats.
The 2024 French legislative election runoff on July 7 yielded surprising results compared to the first round on June 30, with the New Popular Front (NPF) gaining the most seats, followed by French President Macron’s Ensemble party, and the National Rally. Coalition negotiations will follow. In this post, we examine the ongoing online attacks against French political parties and how initial election predictions at 20:00 local time led to a noticeable drop in France’s Internet traffic.
Let’s start with the attacks, and then move on to the Internet traffic trends.
Political parties under attack
As we highlighted last week, the first round of the French elections saw specific DDoS (Distributed Denial of Service) attacks targeting French political party websites. While online attacks are common and not always election-related, recent activities in France, the Netherlands, and the UK confirm that DDoS attacks frequently target political parties during election periods.
Two French political parties were attacked shortly before the first round of elections, and a third party was targeted on June 30. This third party, indicated in green on the chart below, faced attacks on the evening of June 29. Several attempts were thwarted by Cloudflare throughout election day, from 10:00 to 23:00 UTC (12:00 to 01:00 local time). The most intense attack occurred at 19:00 UTC (21:00 local time), reaching nearly 40,000 requests per second, with a total of 620 million DDoS requests recorded on that day (June 29).
Our data indicates that the most significant attack Cloudflare intercepted targeted a party shown in yellow on the chart above. The party had already been attacked on June 23, 2024, and this subsequent attack happened on July 3 at 21:36 UTC (23:36 local time), lasting four minutes and peaking at 151,000 requests per second (rps), making it the second-largest attack we’ve observed on political parties recently. This was comparable in intensity and duration to another attack on a UK political party right after their election.
On the runoff election day, July 7, the party represented by the blue line was again a target, having been attacked previously on June 24, 27, and 29. The most severe of these occurred on June 27, with attacks reaching 118,000 rps during a day that totaled 610 million daily DDoS requests. On July 7, the attacks resumed, with the first starting at 09:55 UTC (11:55 local time) and continuing sporadically until 23:18 UTC (01:18 local time on July 8). The peak of these attacks came at 11:40 UTC (13:40 local time), reaching 96,000 rps.
While these rates may seem small to Cloudflare, they can be devastating for websites not well-protected against such high levels of traffic. DDoS attacks not only overwhelm systems but also serve, if successful, as a distraction for IT teams while attackers attempt other types of breaches.
Exit polls came with a 20:00 Internet traffic dip
Each election brings its own unique circumstances. For instance, the UK’s snap election took place on Thursday, July 4, 2024, aligning with Britain’s tradition of weekday elections. In contrast, France and many other countries hold elections on weekends, typically Sundays.
During the first round of the French elections on June 30, morning traffic was lower than the previous week and rose in the afternoon. The runoff, a week later, displayed a different pattern. Morning traffic remained stable compared to June 30, but it saw a significant decrease in the afternoon, especially after 17:30 local time. Polling stations in major cities closed at 20:00. At this time, TV media began broadcasting the first results, causing a 16% drop in traffic compared to the previous week. This trend, where traffic dips as initial results are announced, is also seen in other elections, like the UK’s.
Traffic shifts during voting day, compared to the previous week, are more revealing when viewed in detail. The map and table below summarize the traffic changes observed at the state level within France, when voting closed and initial results predictions were revealed on TV at around 20:00 local time. This was the moment when, from Cloudflare’s data perspective, attention was diverted from online use.
(Source: Cloudflare; created with Datawrapper)
The table below shows the drops in traffic on July 7, at 20:00 local time, compared to the previous week.
State
Drop in traffic (%)
Bourgogne-Franche-Comté
-19%
Grand Est
-19%
Brittany
-15%
Auvergne-Rhône-Alpes
-15%
Corsica
-14%
Occitanie
-11%
Nouvelle-Aquitaine
-11%
Normandy
-10%
Île-de-France
-10%
Hauts-de-France
-9%
Pays de la Loire
-8%
Provence-Alpes-Côte d’Azur
-7%
Centre-Val de Loire
-6%
On election day in France, Internet traffic decreased most significantly in the regions of Bourgogne-Franche-Comté and Grand Est, both in the eastern part of the country and both experiencing a 19% drop. When comparing these regions to the Île-de-France region, where Paris is located, we see a smaller traffic decrease, at 10%. In the south, in regions like Provence-Alpes-Côte d’Azur, the drop was even less pronounced, at 7%.
Mobile device usage
Also notable was the increase in mobile device request traffic share during both election days, driving the share to levels higher than usual. Over the past month, mobile device traffic share on Sundays typically ranged from 53% to 54%. However, it rose to 57% on the first election day, June 30, and increased further to 58% on the runoff day, July 7, 2024. Mobile device traffic share was especially elevated from 11:00 to 22:00 local time on these days.
DNS trends: news outlets bring results
Switching focus to domain trends, our 1.1.1.1 resolver DNS data reveals a targeted impact from the French elections, allowing for a comparison between the two election days. Analyzing French news media outlets, DNS traffic in France was significantly higher on the first election day, June 30, with a 250% increase at 20:00 local time compared to the previous week. This was 6% higher than on the runoff day, July 7.
For French TV domains, the situation reversed during the runoff on July 7, showing 31% more DNS traffic at 20:00 local time than in the first round. On June 30, DNS traffic at that time was already 274% higher than the previous week, but the increase on July 7 was even more significant, at 391% compared to June 23, 2024—the Sunday before the two election days.
For microblogging social media in France, traffic was higher during the two election days, peaking on the first round. At the close of voting polls at 20:00 local time on June 30, traffic surged 38% compared to June 23, 2024. On July 7, runoff day, traffic increased by 32% at 20:00 local time compared to June 23, but was 4% lower than on June 30.
Conclusion: keeping track of elections
In France, more attention was diverted from the Internet during the decisive runoff election day than in the first round, with a noticeable dip in traffic when TV stations announced predicted results at 20:00 local time.
If you want to follow more trends and insights about the Internet and elections in particular, you can check Cloudflare Radar, and more specifically our new 2024 Elections Insights report, which will be updated as elections take place throughout the year.
The 2024 UK general election, the first since Brexit officially began (January 31, 2020) and after 14 years of Conservative leadership, saw the Labour Party secure a majority. This blog post examines Internet traffic trends and cyberattack activity on election day, highlighting notable declines in traffic during the afternoon and evening as well as a DDoS attack on a political party shortly after polls closed.
The UK’s snap election on Thursday, July 4, 2024, typical of British Thursday weekday elections, contrasts with weekend elections in other countries. Polling stations were open from 07:00 to 22:00.
Generally, election days do not result in drastic changes to Internet traffic. Traffic typically dips during voting hours but not as sharply as during major events like national holidays, and rises in the evening as results are announced.
On July 4, 2024, traffic initially rose slightly from the previous week, then fell around noon (-2%). Significant declines began only after 16:00, with noticeable drops at 16:45 and again at 22:00 as polls closed.
Internet traffic dips across UK countries
Traffic shifts during voting day, compared to the previous week, are more revealing when viewed in detail. The map and table below summarize the traffic changes observed at the country level within the UK, where the greatest impact was observed in Northern Ireland (-10%), followed by Scotland (-6%), Wales (-5%), and England (-3%), all after 16:00.
Country
Drop in traffic (%)
Time of drop in traffic (local)
Northern Ireland
-10%
July 4, 16:00
Scotland
-6%
July 4, 20:00
Wales
-5%
July 4, 17:00
England
-3%
July 4, 16:00
Next, examining the day’s traffic changes, we observed a clear drop in Northern Ireland around 13:00 local time and during off-work hours between 16:00 and 20:00, before it began to increase again.
In Scotland, traffic fell by about 5% from 16:00 to 21:00 local time compared to the previous week.
In Wales, decreases occurred at 07:00 (4% drop), between 16:00 and 18:00 (around 5% drop), and at 21:00.
And in England, traffic decreased by approximately 3% between 16:00 and 18:00 and about 2% between 20:00 and 22:00.
In all the countries within the UK, traffic clearly increased after 23:00 local time when the voting polls had already closed and the first results started to arrive. Peak increases were reached at different times: Wales saw a 3% increase at 01:00; Northern Ireland and England experienced their highest increases of 12% and 11% respectively at 02:00; and Scotland had a 9% increase at 02:00 followed by a 12% spike at 04:00.
DNS trends: news outlets bring results
Switching focus to domain trends, our 1.1.1.1 resolver DNS data reveals a more targeted impact from the UK elections. Analyzing the participating parties, DNS traffic significantly increased on election day, peaking at 22:00 and midnight local time (up to 600% growth), and then again at 04:00 (671%).
Among the main parties, Labour, led by Keir Starmer, outperformed the Conservative Party on election day. Labour’s DNS traffic spiked at 22:00 local time, with an 866% increase from the previous week.
Analyzing official government and election-related websites, the UK differs from other countries in how results are shared. Official results weren’t continuously updated as they came in. The largest spike in DNS traffic, a 172% increase from the previous week, occurred on election morning around 07:00 local time. This increase likely happened because UK citizens were searching for the correct polling stations and other voting resources.
News sites and microblogging social media platforms in the UK experienced significant increases in usage after the polling stations closed at 22:00 local time. In the UK, news sites not only provide initial projections but also final results. DNS traffic for UK news media outlets surged 74% compared to the previous week, peaking at 104% at midnight and 04:00.
For microblogging social media in Great Britain, traffic was already 25% higher than the previous week when the polls closed (22:00), peaking at 27% at midnight and remaining elevated through the night.
We saw last week in the US, during the Biden vs Trump debate, that video streaming social platforms such as YouTube or TikTok, were used to watch through news outlets channels the debate live, with DNS traffic surging. How about the UK? DNS traffic was 10% higher than in the previous week starting at midnight, and at 01:00 local time was 15% higher.
Attacks: political parties included impact
Focusing on attacks, those are usually constant, and aren’t necessarily driven always by elections. But, as we’ve seen at the start of the war in Ukraine or more recently in the Netherlands or in France, specific events do trigger attacks. DDoS (Distributed Denial of Service) attacks remain a common method employed by attackers.
In recent days, there has been DDoS activity targeting political parties in the UK that participated in these elections. Our data shows that two parties experienced attacks that were blocked by Cloudflare. One party, represented in blue, suffered an attack on June 16, which lasted over four hours and peaked at 60,000 requests per second (rps).
The party shown in yellow was hit by four DDoS attacks on different days: June 13, 19, 26, and in the early hours of July 5 (UTC), just after the election’s first predictions were broadcast, giving a majority to the Labour Party. This was the most significant attack in recent days, peaking at 156,000 rps. It began at 01:47 local time (00:47 UTC) and ended four minutes later. Here’s a closer look at that July 5, 2024, attack:
Although these rates are small on Cloudflare’s scale, they can be devastating for unprotected websites unaccustomed to such levels of traffic.
Conclusion: high intensity election year
Even if major political events don’t always bring notable changes to Internet traffic, our data shows that in the UK, traffic decreased more significantly in the afternoon and evening, especially as voting stations remained open until 22:00.
After voting ended, news sites became the go-to resource for UK residents seeking initial predictions and results.
We also observed attacks targeting political parties in the UK, further highlighting that this election year is marked by cyberattacks aimed at influencing politically related websites.
If you want to follow more trends and insights about the Internet and elections in particular, you can check Cloudflare Radar, and more specifically our new 2024 Elections Insights report, which will be updated as elections take place throughout the year.
France is currently electing a new government through early legislative elections that began on Sunday, June 30, 2024, with a second round scheduled for July 7. In this blog, we show how Cloudflare blocked DDoS attacks targeting three different French political parties.
2024 has been dubbed “the year of elections,” with elections taking place in over 60 countries, as we have mentioned before (1, 2, 3). If you regularly follow the Cloudflare blog, you’re aware that we consistently cover election-related trends, including in South Africa, India, Iceland, Mexico, the European Union and the 2024 US presidential debate. We also continuously update our election report on Cloudflare Radar.
Recently in France, as in the early stages of the war in Ukraine and during EU elections in the Netherlands, political events have precipitated cyberattacks. In France, several DDoS (Distributed Denial of Service attack) attacks targeted political parties involved in the elections over the past few days, with two parties hit just before the first round and another on election day itself.
The first political party, shown in yellow in the previous chart, experienced a DDoS attack on June 23, 2024, peaking at 68,000 requests per second (rps); it also endured a second DDoS attack on June 29, the day before the election, peaking at 20,000 rps. Although these rates are small on Cloudflare’s scale, they can be devastating for unprotected websites unaccustomed to such levels of traffic.
The second party, represented by the blue line, was targeted on June 24, June 27, and June 29, 2024, with the most severe attack occurring on June 27, reaching 118,000 rps during a day marked by frequent DDoS spikes that had in total 610 million daily requests.
The third party was attacked on the evening of June 29 in France, with several attempts blocked by Cloudflare on election day, June 30, between 10:00 and 23:00 UTC (12:00 and 01:00 local time). The peak activity targeting this party hit nearly 40,000 rps at 19:00 UTC (21:00 local time), with a total of 620 million daily DDoS requests on election day.
Modest drops and clear traffic increases after voting ends
During the first round of the election this past Sunday, June 30, 2024, Internet traffic was initially higher than the previous week but dropped by as much as 3% at 11:30 local time (09:30 UTC) after the polls opened. Traffic began to increase again after 17:45 local time (15:45 UTC) and peaked at 20:00 local time (18:00 UTC) when the polls closed and the first projections were announced.
We will provide a trends update on the French election after the runoff scheduled for July 7, 2024.
If you want to follow more trends and insights about the Internet and elections in particular, you can check Cloudflare Radar, and more specifically our new 2024 Elections Insights report, which will be updated as elections take place throughout the year.
The Biden vs. Trump debate influenced Internet traffic at the state level in the US, with drops in traffic as high as 17% (in Vermont) during the debate.
Microblogging and video streaming platforms saw traffic changes during the debate.
Trump-related sites, including donation platforms, gained much more traction than Biden’s during and after the debate.
Emails with “Trump” in the subject had higher rates of spam and malicious content compared to those with “Biden.”
No increase in cyberattacks during the debate, but frequent DDoS attacks targeted government and political sites in the preceding months.
Internet traffic ebbs and flows usually follow human patterns, and high visibility events that are broadcast on TV usually have an impact. Let’s take a look at the first of the 2024 United States presidential debates between the two major presumptive candidates, Joe Biden and Donald Trump, for the November presidential election.
Typically, from what we usually observe, election days don’t come with highly intensive changes to Internet traffic, and the same is true for debates. Yet, debates can also draw attention that impacts traffic, especially when there is heightened anticipation. The 2024 debates are not only aired on broadcast and cable television but also streamed on platforms like YouTube, enhancing their reach and impact.
During the June 27, 2024, debate between Biden and Trump, hosted by CNN at 21:00 EST (01:00 UTC), Cloudflare noted a slight drop in nationwide Internet requests, falling to 2% below the same time a week prior at 21:15 EST (01:15 UTC). Interestingly, Internet traffic was 4% higher just before the debate started and surged to 6% above the previous week’s levels after the debate concluded at 23:45 EST (03:45 UTC).
Internet traffic dips across US states
Traffic shifts at the time of the debate, as compared to the previous week, are much more revealing at a state-level perspective than at the country level. The map below summarizes traffic changes observed at a state level:
The most significant traffic drops were seen in Vermont (-17%), South Dakota (-16%), Wyoming (-16%), and Alaska (-16%). More populous states like California, Texas, and New York saw milder reductions of between 5% and 6%, and Florida experienced a 9% drop at 21:45 local time (01:45 UTC) during the debate.
The six swing states that are said to be decisive in the election, Arizona, Georgia, Michigan, Nevada, Pennsylvania and Wisconsin, all saw traffic drop between 5% and 8%.
The initial minutes of the Biden vs. Trump debate triggered the largest traffic declines in most states, though several, including Florida, Louisiana, Georgia, Nevada, and Wisconsin, observed deeper dips midway through. States like Ohio and Missouri recorded their most substantial traffic drops towards the debate’s conclusion.
In the next table, we provide a detailed breakdown of the same perspective shown on the US map ordered by the magnitude of the drop in traffic. We include the time of the biggest traffic drop compared to the previous week, at a 5-minute granularity, and also the percentage of the drop compared to the previous week. (Illinois is not included due to data issues.)
State
Drop in traffic (%)
Time of drop in traffic (local)
Time of drop in traffic (UTC)
Vermont
-17%
21:00
1:00
Alaska
-16%
17:30
1:30
South Dakota
-16%
20:10 / 19:10
1:10
Wyoming
-16%
19:25
1:25
New Hampshire
-13%
21:05
1:05
Rhode Island
-12%
21:05
1:05
Louisiana
-11%
20:45
1:45
Massachusetts
-11%
21:05
1:05
Connecticut
-10%
21:30
1:30
Montana
-10%
19:10 / 18:10
1:10
Nebraska
-10%
20:05 / 19:05
1:05
Oklahoma
-10%
20:05
1:05
Florida
-9%
21:45
1:45
Georgia
-8%
21:45
1:45
Nevada
-8%
18:40
1:40
New Jersey
-8%
21:05
1:05
Ohio
-8%
22:25
2:25
Washington
-8%
18:30
1:30
Kentucky
-7%
21:15
1:15
North Carolina
-7%
21:15
1:15
North Dakota
-7%
20:10 / 19:10
1:10
Wisconsin
-7%
20:45
1:45
California
-6%
18:05
1:05
Iowa
-6%
20:35
1:35
Kansas
-6%
20:05
1:05
Maine
-6%
21:05
1:05
Michigan
-6%
21:05
1:05
Minnesota
-6%
20:05
1:05
New Mexico
-6%
19:10
1:10
Tennessee
-6%
20:30 / 21:30
1:30
Alabama
-5%
20:10
1:10
Arizona
-5%
18:20
1:20
Arkansas
-5%
20:25
1:25
Colorado
-5%
19:15
1:15
Indiana
-5%
21:10
1:10
New York
-5%
21:25
1:25
Pennsylvania
-5%
21:15
1:15
South Carolina
-5%
21:35
1:35
Texas
-5%
20:20 / 19:20
1:20
Idaho
-4%
19:45 / 18:45
1:45
Utah
-4%
19:05
1:05
Virginia
-4%
21:05
1:05
Delaware
-3%
21:05
1:05
Oregon
-3%
18:15
1:15
West Virginia
-3%
21:05
1:05
District of Columbia
-2%
21:55
1:55
Hawaii
-2%
15:20
1:20
Maryland
-2%
21:10
1:10
Mississippi
-2%
20:20
1:20
Missouri
-2%
21:10
2:10
Illinois
–
–
–
DNS trends: Trump-related sites see accelerated growth
Switching focus to domain trends, our 1.1.1.1 resolver data reveals a more targeted impact from the debate. Considering the candidates individually (using the official sites related to both candidates), we found that Biden-associated websites saw a 176% surge in DNS queries at around 23:00 EST (03:00 UTC), compared to the previous week.
However, Trump-associated sites saw a greater increase than Biden-associated sites, showing an increase before, during, and after the debate, with the peak growth reaching 803% over the previous week at 01:00 EST (05:00 UTC).
For donation sites, those linked to Biden were busiest before the debate on June 17 and 18, thanks to events with Barack Obama and Bill and Hillary Clinton. DNS traffic for Trump’s donation sites, as compared with the previous week, increased during the debate, growing 830% at 22:00 EST (02:00 UTC) and reaching a high of 1270% increase by 01:00 EST.
The debate aired on multiple TV channels and was streamed on YouTube. During the debate, video streaming platforms like TikTok and YouTube, which are among the top Internet services globally, saw a 4% increase in DNS traffic at 22:00 EST (02:00 UTC). Significant changes in DNS traffic on these platforms are uncommon due to their widespread popularity.
Political news sites also spiked, with a 68% traffic increase around 22:00 EST (02:00 UTC).
Microblogging social platforms like X or Threads outperformed their previous week’s traffic throughout the debate day, with growth peaking at 41% at the start of the debate around 21:00 EST (01:00 UTC).
Biden vs Trump: spam and malicious emails
In June 2024 (through June 27), Cloudflare’s Cloud Email Security service processed over 2.5 million emails containing “Biden” or “Trump” in the subject line. Trump-related subjects appeared 13% more often than those related to Biden. Moreover, emails with “Trump” had higher percentages of spam, at 3%, and malicious messages, at 0.6%, compared to 0.8% for spam and 0.2% for malicious messages with “Biden.”
The peak occurrence of spam emails with “Trump” was on June 9, at 19.8%, and the highest rate of malicious messages was on June 12, at 2.9%. For “Biden,” the highest spam rate was on June 21, at 1.2%, and the peak for malicious messages was also on June 9, at 0.8%.
Attacks: government and political impact
Focusing on attacks, those are usually constant, and aren’t necessarily driven always by elections. But, as we’ve seen at the start of the war in Ukraine or more recently in the Netherlands, events do trigger attacks. Already in June 2024, during the European elections, we recently published a blog post about the cyberattack on Dutch political-related websites that lasted two days – June 5 and 6. The main DDoS (Distributed Denial of Service attack) attack on June 5, the day before the Dutch election, reached 73,000 requests per second (rps).
Shifting our focus to the US in particular, in the weeks since April 2024, we’ve seen some DDoS attacks targeting both government, state or political-related websites in the United States. That said, we haven’t seen any substantial attacks targeting political sites during the day of debate, June 27. The most recent one we saw was this week, on June 24, and targeted a political-related website involved in the current elections. It was a small attack that lasted under 10 minutes and peaked at 35,000 requests per second (rps).
Now that we’ve explored the US presidential debate trends, let’s compare it with Internet trends from other debates in the UK and France from the week of June 24, 2024.
UK and France: debates with an impact
In other countries like the UK and France, election-related debates during the week of June 24 also serve as examples for comparison with the Biden vs Trump debate. Both the UK and France experienced more significant nationwide traffic impacts during their debates compared to the US. However, the geographic and population size of the US, coupled with the debate’s broad availability on streaming platforms, could have influenced this disparity.
In France, the snap election is scheduled for Sunday, June 30, 2024, and the runoff on July 7, 2024. The final debate among the leading candidates on Tuesday, June 25, 2024 (21:00 local time), led to a 14% drop in Internet HTTP requests, as it was broadcast nationally and carried broad interest. Despite this, the UEFA Euro 2024 football match between France and Poland on the same day, at 18:00 local time, caused an even greater traffic decrease of 16%.
The following day, Wednesday, June 26, 2024, the two main candidates for the snap UK general election — scheduled for July 4, 2024 — participated in their final debate on BBC national TV. The debate between Rishi Sunak and Sir Keir Starmer, which started at 20:15 local time, resulted in a 7% drop in UK Internet traffic compared to the previous week. The most significant decrease occurred at 20:45. At a more detailed level, Wales experienced an 11% drop during the debate, followed by England at 8%, Scotland at 7%, and Northern Ireland at 5%.
Conclusion: high intensity election year
Even if major political events don’t always bring significant changes to Internet traffic, our data shows that the Biden vs. Trump debate had an impact, especially at the state level. Microblogging and video streaming social platforms also saw traffic shifts during the debate, with Trump-related sites seeing larger spikes in DNS traffic than Biden-related sites, especially after the debate.
We also observed a higher percentage of spam and malicious emails sent with “Trump” in the subject of the messages than with “Biden.” Although we didn’t see an uptick in cyberattacks during the debate, we note that these have been frequent, especially DDoS attacks in the months before, targeting both federal and state government services as well as politically related sites.
If you want to follow more trends and insights about the Internet and elections in particular, you can check Cloudflare Radar, and more specifically our new 2024 Elections Insights report, which will be updated as elections take place throughout the year.
Football (“soccer” in the US) is considered the most popular sport in the world, with around 3.5 billion fans spread across the world. European football is central to its popularity. The UEFA Euro 2024 (the European Football Championship) started on June 14 and will run until July 14, 2024. But how much do these games impact Internet traffic in countries where national teams are playing? That’s what we aim to explore in this blog post. We found that, on average, traffic dropped 6% during games in European countries with national teams playing in the tournament.
Cloudflare has a global presence with data centers in over 320 cities, which helps provide a global view of what’s happening on the Internet. This is helpful for security, privacy, efficiency, and speed purposes, but also for observing Internet disruptions and traffic trends.
In the past, we’ve seen how Internet traffic and HTTP requests are impacted by events such as total solar eclipses, the Super Bowl, and elections. 2024 is the year of elections, and we’ve been sharing our observations in blog posts and our new 2024 Election Insights report on Cloudflare Radar.
However, football games are different from elections. Related trends happen when major teams or national squads are playing matches that draw a lot of human attention. If a game is broadcast on a national TV channel, Internet traffic typically drops because during games. People’s attention is more on the TV set with the ‘old’ broadcast signal, for those games that don’t require a paid subscription. That’s the most common situation when national teams are playing in Europe.
If it’s on a closed or paid channel (where a subscription is needed), then sometimes traffic increases as fewer viewers have access to the TV broadcast. For context, there’s a trend of channels offering games in their apps through streaming, not only for paid channels but also national broadcasters such as the British BBC. The opening England game in Euro 2024 on Sunday, June 16, 2024, had 15 million viewers on BBC One and was also streamed 3.5 million times on BBC iPlayer. This variety of viewing options from a single service appears to be a new trend in the digital age.
Football games associated with drops in traffic
Now, for some game-related Internet trends: the Netherlands, Turkey, Belgium, Croatia, Slovakia, Serbia, and host Germany were the countries where their national team games had a significant impact on requests, with a drop of at least 12% compared to the previous week. Western Europe and countries around Germany top the list. The list shown in the map and the table below covers the first round of games among all teams in all six groups, which concluded on June 19, 2024.
Here is the full list, which provides more detail than the map above, showing each country and the percentage decrease (or increase) in traffic as compared to the previous week at the time those countries’ national team games were occurring.
Country
Increase/ decrease traffic
Game day/hour (UTC)
Opponent
Netherlands
-18%
June 16, 13:00
Poland
Turkey
-16%
June 18, 16:00
Georgia
Belgium
-15%
June 17, 16:00
Slovakia
Croatia
-14%
June 15, 16:00
Spain
Slovakia
-14%
June 17, 16:00
Belgium
Serbia
-13%
June 16, 19:00
England
Germany
-12%
June 14, 19:00
Scotland
Denmark
-10%
June 16, 16:00
Slovenia
Slovenia
-10%
June 16, 16:00
Denmark
Switzerland
-9%
June 15, 13:00
Hungary
England
-8%
June 16, 19:00
Serbia
Georgia
-8%
June 18, 16:00
Turkey
Austria
-7%
June 17, 19:00
France
Hungary
-7%
June 15, 13:00
Switzerland
Spain
-7%
June 15, 16:00
Croatia
France
-6%
June 17, 19:00
Austria
Scotland
-6%
June 14, 19:00
Germany
Portugal
-6%
June 18, 19:00
Czechia
Italy
-3%
June 15, 19:00
Albania
Czechia
-3%
June 18, 19:00
Portugal
Ukraine
9%
June 17, 13:00
Romania
Poland
12%
June 16, 13:00
Netherlands
Romania
16%
June 17, 13:00
Ukraine
Albania
25%
June 15, 19:00
Italy
Albania, Romania, Poland, Ukraine, and Slovenia were the only countries with an increase in HTTP requests during games. England (-8%) and Scotland (-6%) both have similar drops in requests during their national team games.
We’ve also noticed looking at our country-related HTTP data around games that social media services usually go up during half-time and before and after these national team games. As expected, traffic to websites in categories like AI chatbots, ecommerce (though some see increases during halftime), productivity tools, and business and financial services tends to decrease during Euro 2024 games.
First day of competition: Germany-Scotland
Another important perspective is focused on the first day of competition. On June 14, 2024, Euro 2024 kicked off in Germany. How was Internet traffic impacted in the country?
When the ceremony started around 18:45 UTC (20:45 local time), by as much as 11%, deepening to a 12% drop from the previous week when the first game between Germany and Scotland began at 19:00 UTC (21:00 local time). Traffic briefly recovered during halftime to only 4% below the previous week’s levels, but fell again to 11% below the prior week during the second half. At 00:00 UTC (02:00 local time), requests dropped as much as 19% from the previous week, in a night of celebration for German fans.
The second round of games in the Euro 2024 group phase is already underway. We’re keeping an eye on country-related trends after games on X.
An attacks perspective
During the UEFA Euro 2024 event in Germany, we’ve observed several attacks in the country. These included application layer DDoS (Distributed Denial of Service) attacks targeting various websites, such as a translation tool, a data protection tool, a search engine, and a local government website. The most significant DDoS attack occurred on June 15, 2024, the day after the competition started, targeting the translation tool. This attack reached 105 million requests per hour at 23:00 UTC and lasted about two hours with two distinct spikes.
Looking more closely at the attack on the translation tool, it peaked at 1.74 million requests per second (rps) at 23:40 UTC, following an initial spike of 147,000 rps at 21:04 UTC.
Conclusion
Football is incredibly important to Europeans, enough to cause nationwide Internet traffic to drop when fans are rooting for their national teams in a UEFA Euro 2024 game broadcast on national TV.
Despite the popularity of online services like live score apps, sports news sites that track every minute of each game, and betting services enhanced with new visual tools and stats, national team football (or soccer) still significantly diverts attention away from the Internet.
We will continue to monitor UEFA Euro 2024 Internet trends. Based on the results of a poll we conducted on X, we plan to publish daily updates about games and their impact on countries whose national teams are playing that day. Follow us there.
The practice of cheating on exams (or at least attempting to) is presumably as old as the concept of exams itself, especially when the results of the exam can have significant consequences for one’s academic future or career. As access to the Internet became more ubiquitous with the growth of mobile connectivity, and communication easier with an assortment of social media and messaging apps, a new avenue for cheating on exams emerged, potentially facilitating the sharing of test materials or answers. Over the last decade, some governments have reacted to this perceived risk by taking aggressive action to prevent cheating, ranging from targeted DNS-based blocking/filtering to multi-hour nationwide shutdowns across multi-week exam periods.
Syria and Iraq are well-known practitioners of the latter approach, and we have covered past exam-related Internet shutdowns in Syria (2021, 2022, 2023) and Iraq (2022, 2023) here on the Cloudflare blog. It is now mid-June 2024, and exams in both countries took place over the last several weeks, and with those exams, regular nationwide Internet shutdowns. In addition, Baccalaureate exams also took place in Algeria, and we have written about related Internet disruptions there in the past (2022, 2023). However, in contrast to the single daily shutdowns in Syria and Iraq, the Algerian government opted instead for two multi-hour disruptions each day – one in the morning, one in the afternoon – and appears to be pursuing a content blocking strategy, rather than a full nationwide shutdown.
As we have done in past year’s posts, we will examine the impact that these shutdowns have on Internet traffic, but also analyze routing information and traffic from other Cloudflare services in an effort to better understand how these shutdowns are being implemented.
Syria
The Syrian Telecom Company, to their credit, publishes an exam schedule on social media, with the image below published to their Facebook page. The English version was created by applying Google Translate to the image. The schedule shows the date & time of each Internet shutdown (“disconnection”), in addition to the subject(s) of that day’s exam(s). In 2024, exams started on May 26, and went through June 13.
In Syria, AS29256 (Syrian Telecom) is effectively the Internet, as shown in the table below. While there are a few other autonomous systems (ASNs/ASes) registered in Syria, there are only two that currently announce IP address space to the public Internet. As such, the trends seen at a country level for Syria reflect those seen for AS29256, and this is clearly evident in the traffic graphs below.
Nationwide Internet shutdowns in Syria began on May 26, taking place for varying multi-hour periods from Sunday to Thursday for three consecutive weeks. The graphs below show Internet traffic from the country, as well as AS29256, dropping to zero during the scheduled shutdowns.
In addition, graphs from the Cloudflare Radar Routing pages for Syria and AS29256 show the number of IPv4 and IPv6 prefixes being announced country-wide and by AS29256 dropping to at or near zero during each shutdown. This ultimately means that there is no Internet path back to systems (IP addresses) connected to Syrian Telecom. Below, we explore why this is important and problematic.
As has been observed in the past, the shutdowns in Syria are asymmetrical. That is, traffic can exit the country (via AS29256), but there are no paths for responses to return. The impact of this approach is clearly evident in traffic to Cloudflare’s 1.1.1.1 DNS Resolver. We continue to see traffic to the resolver when the shutdowns take place, and in fact, we see the traffic spike during the shutdowns, as the graph below shows.
If we dig into traffic to 1.1.1.1 by protocol, we can see that it is driven by requests over UDP port 53, the standard port used for DNS requests over UDP and TCP. (Given the request pattern, that also appears to be the primary way that we see traffic to the resolver from Syria.)
If we remove the UDP line from the graph, we see that request volume for DNS over TCP port 53, as well as DNS over HTTPS (DoH) and DNS over TLS (DoT), all drops to zero during the shutdowns.
Similarly, we can clearly see the shutdowns in HTTP(S) request-based traffic graphs as well, since HTTP(S) is also a TCP-based protocol.
Why do we see this impact? With DNS over UDP, the client simply makes a request to the resolver – no multi-step handshake is involved, as with TCP. So in this case, 1.1.1.1 is receiving these requests, but as shown above, there’s no path for the response to reach the client. Because it hasn’t received a response, the client retries the request, and this flood of retries is manifested as the spike seen in the graphs above.
However, as we see above, request volume for DNS over TCP, as well as DoH, DoT, and HTTP(S) (which all use TCP), falls to zero during the shutdowns. The lack of a path back to the client means that the TCP 3-way handshake can’t complete, and thus we don’t see DNS requests over these protocols.
In looking at 1.1.1.1 Resolver request volume from Syria for popular social media and messaging applications, we can see traffic for facebook.com most closely matches the spikes shown above. Removing facebook.com from the graph, we can also see similar, though more limited, increases for domains used by popular messaging applications WhatsApp, Signal, and Telegram. Facebook and WhatsApp are reportedly the most popular social media and messaging applications in Syria.
Although we have focused on the analysis of traffic to Cloudflare’s DNS resolver, and the patterns seen within that traffic, it is also worth highlighting an interesting pattern observed in traffic to Cloudflare’s Authoritative DNS platform. (DNS resolvers act as a middleman between clients, such as a laptop or phone, and an authoritative DNS server. Authoritative DNS servers contain information specific to the domain names they serve, including IP addresses and other types of records.)
The graph below shows bits/second traffic from Syria for Cloudflare’s authoritative DNS service on June 13. (Similar patterns were observed during the other days when shutdowns occurred, but data volume limits the ability to create a graph showing an extended period of time.) In this graph, we can see that at the start of the shutdown (03:00 UTC), traffic rises sharply, effectively plateaus for the duration of the shutdown, and then returns to normal levels. We believe that the traffic pattern illustrated here could be the result of some local resolvers in Syria having the IP addresses for our authoritative DNS servers cached, and are making requests to them. The increased traffic level could be because they are retrying their queries after not receiving responses, but in a less aggressive fashion than the client applications driving the resolver traffic spikes shown above.
In summary, Syria appears to be implementing their Internet shutdowns not through filtering, but rather by simply not announcing their IP address space for the duration of the shutdown, thereby preventing any responses from returning to the originating requestor, whether client application, web browser, or local DNS resolver.
Iraq
On May 19, the Iraqi Ministry of Communication posted an update that stated (translated) “The Ministry of Communications would like to note that the Internet service will be cut off for two hours during the general exams for intermediate studies, from six in the morning until eight in the morning, based on higher directives and at the request of the Ministry of Education.” The post came nearly a year after the Iraqi Ministry of Communication refused a request from the Ministry of Education to shut down the Internet during the baccalaureate exams as part of efforts to prevent cheating. On May 20, the Iraqi Ministry of Education posted the schedule for the upcoming set of exams to its Facebook page.
Iraq has a much richer network service provider environment than Syria does, with over 150autonomous systems (ASNs) registered in the country and announcing IP address space, compared to just two ASNs (both Syrian Telecom) in Syria announcing IP address space. Although traffic in Iraq is generally concentrated among the larger providers, shutdowns are rarely “complete” at a country level because not every autonomous system (network provider) in the country implements a shutdown. (This is due in part to the autonomous Kurdistan region in the north, which often implements similar shutdowns on their own schedule. Network providers in this region are included in Iraq’s country-level graphs.)
We can see this in a Cloudflare Radar traffic graph that shows the shutdowns at a country level, where traffic is dropping by around 87% during each multi-hour shutdown. In addition to the five networks also shown here (AS203214 (HulumTele), AS199739 (Earthlink), AS58322 (Halasat), AS51684 (Asiacell), and AS59588 (Zainas)), further analysis finds more than 30 where we observed a complete loss of traffic during the shutdowns, with a number of them downstream of these providers.
In contrast to Syria, the changes to announced IP address space during the shutdowns are much less severe in Iraq. Several of the shutdowns are correlated with a drop of ~20-25% in announced IPv4 address space, while a few others saw a drop closer to just 2%.
Similar to Syria, we can also look at 1.1.1.1 resolver traffic data to better understand how the shutdowns are being implemented. The country-level graphs below suggest that UDP traffic patterns are not visibly changing, suggesting that responses from the resolver are, in fact, getting back to the clients. However, this likely isn’t the case, and such a conclusion is at least in part an artifact of the graph’s time frame and hourly granularity, as well as the inclusion of resolver traffic from Kurdish network providers (ASNs). The shutdowns are more clearly evident in the DNS-over-TCP and DNS-over-HTTPS graphs below, as well as in the graph for HTTP(S) request traffic (both mobile & desktop), which is also TCP-based. In these graphs, the troughs on days that shutdowns occurred generally dip lower than those on the days that the Internet remained available.
In looking at authoritative DNS traffic from Iraq during a shutdown (for June 13 as an example day, as above), we see evidence of a decline in traffic during the time the shutdown occurs.
The decline in authoritative DNS traffic is more evident at an ASN level, such as in the graph below for AS203214 (Hulum), effectively confirming that UDP traffic is not getting through here either.
Considering the traffic, 1.1.1.1 Resolver, and authoritative DNS observations reviewed here, it suggests that the Internet shutdowns taking place in Iraq are more complex than Syria’s, as it appears that both UDP and TCP traffic are unable to egress from impacted network providers. As not all impacted network providers are showing a complete loss of announced IP address space during the shutdowns, Iraq is taking a different approach to disrupting Internet connectivity. Although analysis of our data doesn’t provide a definitive conclusion, there are several likely options, and network providers in the country may be combining several. These options revolve around:
IP: Block packets from reaching IP addresses. This may be done by withdrawing prefix announcements from the routing table (a brute force approach) or by blocking access to specific IP addresses, such as those associated with a specific application or service (a more surgical approach).
Connection: Block connections based on SNI/HTTP headers, or other application data. If a network or on-path device is able to observe the server name (or other relevant headers/data), then the connection can be terminated.
DNS: Operators of private or ‘internal’ DNS resolvers, offered by ISPs and enterprise environments for use by their own users, can apply content restrictions, blocking the resolution of hostnames associated with websites and other applications.
The consequences of these options are covered in more detail in a blog post. In addition, applying them at common network chokepoints, such as AS212330 (IRAQIXP) or AS208293 (AlSalam State Company, associated with the Iraqi Ministry of Communications), can disrupt connectivity at multiple downstream ISPs, without those providers necessarily having to take action themselves.
Algeria
As we noted in blog posts in 2022 and 2023, Algeria has a history of disrupting Internet connectivity during Baccalaureate exams. This has been taking place since 2018, following widespread cheating in 2016 that saw questions leaked online both before and during tests. On March 13, the Algerian Ministry of Education announced that the Baccalaureate exams would be held June 9-13. As expected, Internet disruptions were observed both country-wide and at a network level. Similar to previous years, two disruptions were observed each day. The first one began at 08:00 local time (07:00 UTC), and except for June 9, lasted three hours, ending at 11:00 local time (10:00 UTC). (On June 9, it lasted until 13:00 local time (12:00 UTC).) The second one began between 14:00-14:30 local time (13:00-13:30 UTC), and lasted until 16:00-17:00 local time (15:00-16:00 UTC) – the end time varied by day.
As seen in the graphs below, the impact to traffic was fairly nominal, suggesting that wide scale Internet shutdowns similar to those seen in Syria were not being implemented. While this is in line with 2023’s pronouncement by the Minister of Education that there would be no Internet shutdown on exam days, a number of posts on X complained of broader cuts to Internet connectivity.
Similar to the analysis above of the shutdowns in Syria and Iraq, we can also review changes to announced IP address space to better understand how connectivity was being disrupted. In this case, as the graphs below show, no meaningful changes to announced IPv4 address space were observed during the days the Baccalaureate exams were given. As such, the observed drops in traffic were not caused by routing changes.
In the HTTP(S) request traffic graph below, the twice-daily disruptions are highlighted, with the morning one appearing as a nominal drop in traffic, and the afternoon one causing a more severe decline. (The graph shows request traffic aggregated at a country level, but the graphs for the ASNs listed above also show similar patterns.)
In addition, similar patterns are observed in 1.1.1.1 resolver traffic at a country and ASN level, but only for DNS over TCP, DNS over TLS, and DNS over HTTPS, all of which leverage TCP. In the graph below showing only resolver traffic over UDP, there’s no clear evidence of disruptions. However, in the graph that shows resolver traffic over HTTPS, TCP, and TLS, a slight perturbation is visible in the morning, as traffic begins to rise for the day, and a sharper decrease is visible in the afternoon, with both disruptions aligning with the twice daily drops in traffic discussed above.
These observations support the conjecture that the Algerian government is likely taking a more nuanced approach to restricting access to content, interfering in some fashion with TCP-based traffic. The conjecture is also supported by an internal tool that helps to understand connection tampering that is based on research co-designed and developed by members of the Cloudflare Research team. We will be launching insights into TCP connection tampering on Cloudflare Radar later in 2024 and, in the meantime, technical details can be found in the peer-reviewed paper titled Global, Passive Detection of Connection Tampering.
The graph below, taken from the internal tool, highlights observed TCP connection tampering in connections from Algeria during the week that the Baccalaureate exams took place. While some baseline level of post-ACK and post-PSH tampering is consistently visible, we see significant increases in post-ACK twice a day during the exam period, at the times that align with the shifts in traffic discussed above. Technical descriptions of post-ACK and post-PSH tampering can be found in the Cloudflare Radar glossary, but in short, tampering post-ACK means an established TCP connection to Cloudflare’s server has been abruptly ended by one or more RST packets before the server sees data packets. Although clients do use RSTs, clients are more likely to close connections with a FIN (as specified by the RFC). The RST method can also be used by middleboxes that (i) sees the data packet, then (ii) drops the data packet, then (iii) sends an RST to the server to force the server to close the connection (and very likely another RST to the client too for the same reason). Tampering post-PSH means that something on the path, like a middlebox, (i) saw something it didn’t like on an established connection, then (ii) permitted the data to pass but then, (iii) it sends the RST to force endpoints to close the connection.
Looking beyond Cloudflare-sourced data, aggregated test results from the Open Observatory of Network Interference (OONI) also show evidence of anomalous behavior. Using OONI Probe, a mobile and desktop app, can probe for potential blocking of websites, instant messaging apps, and censorship circumvention tools. Examining test results from users in Algeria for popular messaging platforms WhatsApp, Telegram, Signal, and Facebook Messenger for the first two weeks of June, we clearly see the appearance of test results marked as “Anomaly” starting on June 9. (OONI defines “Anomaly” results as “Measurements that provided signs of potential blocking”.) OONI Tor testresults also show a similar “Anomaly” pattern. Anomalous traffic patterns are also visible for Google Web Search, YouTube, and GMail.
Although the analysis of these observations and data sets doesn’t provide us with specific details around exactly how the observed Internet disruptions are being implemented, it strongly supports the supposition that network providers in Algeria are, in some fashion, interfering with TCP connections, but not blocking them outright nor shutting down their networks completely. Given that popular messaging platforms, Google properties, Cloudflare’s 1.1.1.1 DNS resolver, and some number of Cloudflare customer sites all appear to be impacted, it suggests that a list of hostnames are being targeted for disruption/interference, either by the SNI or the destination IP address.
Conclusion
Perhaps recognizing the broad negative impact that brute-force nationwide Internet shutdowns have as a response to cheating on exams, some governments appear to be turning to more nuanced techniques, such as content blocking or connection tampering. However, because these are widely applied as well, they are arguably just as disruptive as a full nationwide Internet shutdown. The cause of full shutdowns, such as those seen in Syria, are arguably easier to diagnose than the disruptions to connectivity seen in Iraq and Algeria, which appear to use approaches that are hard to specifically identify from the outside.
The 2024 European Parliament election took place June 6-9, 2024, with hundreds of millions of Europeans from the 27 countries of the European Union electing 720 members of the European Parliament. This was the first election after Brexit and without the UK, and it had an impact on the Internet. In this post, we will review some of the Internet traffic trends observed during the election days, as well as providing insight into cyberattack activity.
Elections matter, and as we have mentioned before (1, 2), 2024 is considered “the year of elections”, with voters going to the polls in at least 60 countries, as well as the 27 EU member states. That’s why we’re publishing a regularly updated election report on Cloudflare Radar. We’ve already included our analysis of recent elections in South Africa, India, Iceland, and Mexico, and provided a policy view on the EU elections.
The European Parliament election coincided with several other national or local elections in European Union member states, leading to direct consequences. For example, in Belgium, the prime minister announced his resignation, resulting in a drop in Internet traffic during the speech followed by a clear increase after the speech was over. In France, we saw a similar pattern with the announcement of legislative snap elections.
From analyzing patterns seen during previous elections in France and Brazil, we know that Internet traffic often decreases during voting hours, though not as significantly as during other major events like national holidays. This usual drop is typically followed by an increase in traffic as election results are announced.
Let’s start with a wider picture of the 2024 European Parliament election, focusing on the time of the biggest drop in Internet HTTP requests during the election days as compared to the previous week. Note that there were some national or local elections taking place at the same time, and European Union elections are known to have low turnout compared to national and local ones.
Source: Cloudflare; created with Datawrapper
Drops greater than 10% were observed only in the Czech Republic, Luxembourg, Slovakia, Cyprus, Belgium, Estonia, and Croatia. The table below includes the percentage that traffic dropped and the specific time during the election day it occurred. In countries with more than one election day, we considered the time and day of the biggest drop.
Countries
Elections day(s)
Local time
Drop in traffic %
Czech Republic
June 7 – 8
June 8, 14:30
-20%
Luxembourg
June 9
12:45
-18%
Slovakia
June 8
15:45; 19:00
-16%
Cyprus
June 9
10:00
-16%
Belgium
June 9
11:45
-14%
Estonia
June 7-9
June 9, 9:00
-13%
Croatia
June 9
18:00
-12%
Poland
June 9
18:00
-10%
Netherlands
June 6
10:15
-10%
Germany
June 9
13:45
-10%
Ireland
June 7
7:15
-9%
Finland
June 9
9:00
-9%
Portugal
June 9
15:45
-9%
Malta
June 8
12:15
-9%
Latvia
June 8
08:30, 16:15
-9%
Slovenia
June 9
18:00
-8%
Hungary
June 9
6:00
-8%
Austria
June 9
12:30
-7%
Italy
June 8 – 9
June 9, 16:00
-6%
France
June 9
13:30
-6%
Bulgaria
June 9
19:45
-5%
Greece
June 9
8:00
-5%
Spain
June 9
13:00
-4%
Lithuania
June 9
8:00
-3%
Romania
June 9
9:45
-1%
Denmark
June 9
–
–
Sweden
June 9
–
–
The data in the list above shows that Central European countries had the highest drop in Internet traffic, particularly the Czech Republic and Slovakia. Eastern Europe saw significant drops in Estonia and Poland. Southern Europe had consistent moderate drops across multiple countries, with Cyprus and Croatia showing higher losses. Northern Europe showed minimal to no traffic drop in Scandinavian countries, with Finland and Ireland experiencing moderate declines.
Looking at the specific (local) times of day during voting periods on election days, morning drops (06:00 – 10:00) were more common in Northern and Eastern Europe. Late morning to early afternoon drops (10:15 – 14:30) were predominantly observed in Western and Central Europe. Late afternoon drops (15:45 – 19:45) were more common in Central and Southern Europe.
Impact of notable announcements in Belgium and France
There’s more to say when we look at specific country trends. The 27 members of the European Union bring diversity in habits, languages, and cultures. That also impacted traffic, and this election in particular had a national impact in some of the countries.
In Belgium, national and regional elections took place on the same day, June 9. After polling stations closed at 16:00 local time (14:00 UTC), HTTP requests followed the typical pattern of increasing, peaking at 21:15 local time (19:15 UTC), with 7% more requests than the previous week. This trend was interrupted by Prime Minister Alexander De Croo’s speech at around 22:00 local time (20:00 UTC), admitting defeat in the national elections. This pattern is typical when important announcements are broadcast on TV, impacting Internet traffic.
How about France? President Emmanuel Macron announced at around 21:00 local time (19:00 UTC) that he would dissolve the national parliament for a snap legislative election. This followed the EU elections that gave a victory to his rival Marine Le Pen’s National Rally in the European Parliament vote. At the time of his speech, requests dropped 6% compared to the previous week, and increased right after Macron’s speech, peaking at 22:15 local time (20:15 UTC) with a 6% increase.
After voting ends, traffic increases
It was not only Belgium and France that had typical increases in HTTP requests at night when the first projections and results started to be announced. The same happened in the Netherlands, the first European country to enter the 2024 European Parliament election, on Thursday, June 6.— We have previously written about Dutch political websites being attacked on that day. Traffic was 4% higher than usual after 20:30 local time (18:30 UTC), and peaked at 01:15 with a 15% increase compared to the previous week.
Similar trends were seen in Italy on June 9, and in Germany on the same day. In Germany, at 21:45 (19:45 UTC), requests were already 8% higher, with a 23:00 (21:00 UTC) drop of 2% during election speeches, and a peak at 00:30 (22:30 UTC) with an 18% increase.
The same night-time trends were observed in other countries:
Slovakia had a peak increase of 24% at 23:45 local time (21:45 UTC) on June 8.
Spain saw a 21% peak increase at 21:00 local time (19:00 UTC) on June 9.
Poland had a 9% peak increase at 01:45 local time (23:45 UTC).
Portugal experienced a 29% peak increase at 00:15 local time (23:15 UTC).
Croatia had a 19% peak increase at 23:00 (21:00 UTC).
Slovenia had a 19% peak increase at 22:45 (20:45 UTC).
Lithuania had a 22% peak increase at 23:00 (20:00 UTC).
Estonia saw the highest peak increase, reaching 35% at 00:00 (21:00 UTC).
Growing interest in election information and news
Switching to domain trends, DNS traffic (using our 1.1.1.1 resolver) shows a more specific impact related to elections. Social media platforms invited users in Europe to vote, sometimes giving European or local websites as a reference. Here’s an example from Instagram:
Did this increase traffic to election-related sites in the European Union? Our DNS data shows a 26x peak growth at 19:00 UTC on Sunday, June 9, 2024. DNS traffic was already much higher compared to the previous week on June 8, with a peak growth of 8x at 17:00 UTC.
Looking at European news outlets’ domains, there was an initial 1.68x increase (compared to the previous week) at 13:00 UTC on June 9, 2024, and a second peak at 19:00 UTC.
For local election-results sites, there was a significant 55x peak growth at 22:00 UTC on June 9, 2024, compared to the previous week.
Government-focused cyberattacks
Focusing on attacks, as mentioned above, we recently published a blog post about the cyberattack on Dutch political-related websites that lasted two days – June 5 and 6. The main DDoS (Distributed Denial of Service attack) attack on June 5, the day before the Dutch election, reached 73,000 requests per second (rps).
Looking at government or state-related websites in the European Union in 2024, there have been several spikes in attacks targeting defense organizations, European courts, and educational institutions since the year started.
The main one was on February 25, 2024, when Cloudflare blocked a DDoS attack on a French government website that reached 420 million requests per hour and lasted over three hours.
Between January and June 2024, government sites in Belgium, France, and Germany were the main targets, receiving 49%, 25%, and 10% respectively of attack requests targeting EU government-related sites.
In a broader view, from January 1 to June 9, Cloudflare mitigated 8.6 billion threats to government websites in the EU, with 68% of those being DDoS threats. This amounts to an average of 53.42 million threats mitigated per day. These trends highlight the ongoing threat to critical infrastructure across Europe, with government sites frequently targeted by cyberattacks.
Just before the elections
Focusing on the five weeks before the EU election, we didn’t see significant attacks on European election-related organizations. However, there were a few DDoS threats that targeted government sites from European Union member states. Notable instances include attacks on the Bulgarian government on June 6, the French government on May 11 and June 9, another in France on May 23, Sweden on May 18 and April 29, and Denmark on May 7.
These attacks were not very large compared to others mentioned. The largest targeted the Bulgarian government on June 6, with 122 million daily DDoS requests and a peak of 110,500 requests per second at 11:29 local time (08:29 UTC).
On election day in France, June 9, a French government website was also the target of a smaller attack, with 42,000 DDoS requests per second at 11:57 local time (09:57 UTC).
Conclusion
The 2024 European Parliament election had some clear impacts on Internet traffic, and cyber threats were looming in the weeks before, most notably the Dutch political-related attack around election day.
While voting led to typical drops in Internet traffic, the announcement of results and significant political events caused spikes in activity.
If you want to follow more trends and insights about the Internet and elections in particular, you can check Cloudflare Radar, and more specifically our new 2024 Elections Insights report, that we’re updating as elections take place throughout the year.
The collective thoughts of the interwebz
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.
