The World’s Biggest DNS Outages: What Actually Caused Them and How to Avoid Being Next

When a major online service suddenly disappears, the first assumption is often that someone is attacking it.

Sometimes that is exactly what happened. The Dyn outage in 2016 is a good example. But look at the post-mortems from some of the largest DNS and internet infrastructure outages of the past decade and a different pattern starts to emerge.

Many were caused by something far more ordinary: a configuration change, a maintenance command, a software bug or an automated process behaving in an unexpected way.

That may be less dramatic than a cyberattack, but for IT operations teams, SREs and CTOs, it is arguably more important. You cannot control whether an attacker decides to target your organization. You can control how changes are managed, how quickly they can be rolled back and whether the failure of a single provider is enough to take your applications offline.

The incidents below show why those things matter.

The scoreboard: the biggest DNS outages and their real causes

Before getting into the individual incidents, it is useful to see them side by side. What stands out is how few were actually caused by attacks.

The Dyn attack of October 2016 remains the clearest attack-driven DNS outage on this list. The Mirai botnet hammered managed DNS provider Dyn and disrupted access to Twitter, Spotify, Reddit, GitHub, PayPal and other major services for hours. Sony alone reported a $2.7 million loss.

But Dyn is the exception here. Every headline DNS-related outage from the 2020s in the table above was self-inflicted in some way.

That does not mean the people or companies involved were careless. Quite the opposite. These were some of the world’s largest and most sophisticated technology organizations. The problem is that ordinary changes can have extraordinary consequences when they meet complex infrastructure without sufficient guardrails.

Meta, October 2021: how one command erased Facebook from the internet

On October 4, 2021, Facebook, Instagram, WhatsApp and Oculus disappeared for roughly six hours. Around 3.5 billion users were suddenly unable to access services they used every day.

According to Meta’s engineering post-mortem, the incident began during routine backbone maintenance. An engineer issued a command intended to assess the capacity of Meta’s global backbone network. An audit-tool bug that should have stopped the command failed to do so, and the command severed Facebook’s backbone connections.

That is when DNS became part of the story.

Meta’s DNS servers could no longer reach its data centers, so they withdrew their BGP route advertisements. Without those routes, the rest of the internet effectively lost the directions it needed to reach Facebook’s services. Facebook.com had, for practical purposes, disappeared from the internet.

Meta was explicit about the cause, stating that it believed the root of the outage was a faulty configuration change.

The failure also exposed another problem. Meta’s internal tools and remote access systems depended on the same network that had just gone down. Engineers could not simply log in remotely and undo the change. Some had to physically enter data centers to restore access.

The estimated loss in advertising revenue was around $60 million.

DNS was therefore the visible symptom of the outage, but the real problem started with a configuration change and became much worse because of interconnected dependencies. The important question for other organizations is not whether they could make exactly the same mistake as Meta. It is whether one ordinary infrastructure change could create a similar chain reaction in their own environment.

Cloudflare: three outages, three different causes, one familiar pattern

Cloudflare provides an interesting comparison because it experienced three significant outages between 2020 and 2025. Each involved a different part of the infrastructure, but all three started with changes that nobody expected to be dangerous.

July 17, 2020: 27 minutes

In July 2020, an engineer misconfigured Cloudflare’s backbone network so that all inter-data-center traffic was sent through a single router in Atlanta. The router was quickly overwhelmed.

Cloudflare’s own summary was very clear that the disruption was not the result of an attack. It was caused by a network configuration error.

For Cloudflare customers, the consequences were immediate. GitLab.com, which relied on Cloudflare’s DNS and CDN services, was unreachable for approximately 22 minutes.

That is an important point. Your servers can be completely healthy, but if the DNS or network infrastructure people use to reach them is unavailable, your application is unavailable too.

June 21, 2022: 1 hour 15 minutes

Two years later, Cloudflare experienced another outage during a planned architecture rollout across 19 of its busiest data centers.

Those data centers represented only around 4% of Cloudflare’s network by location count, but they handled approximately 50% of its total requests.

During the rollout, a term in a BGP prefix-policy configuration was ordered incorrectly. Critical prefixes were withdrawn and traffic could no longer reach parts of the network as expected.

Discord, Shopify, Fitbit and FTX were among the services affected. GitLab recorded 101 minutes of impact.

Again, this was planned work. The change itself was intentional. The outcome was not.

November 18, 2025: approximately 5 hours 46 minutes

Cloudflare’s November 2025 incident was its worst outage since 2019.

This time, the trigger was a routine permissions change to a database cluster. That change caused a Bot Management feature file to double in size and exceed a hard limit in Cloudflare’s proxy software. The oversized configuration file then caused a core traffic-handling module to crash globally.

X, ChatGPT, Spotify and Zoom were among the affected services. Even Downdetector experienced problems.

The intermittent nature of the failure initially made the incident look like a DDoS attack. Cloudflare later went out of its way to make clear that the issue was not caused, directly or indirectly, by a cyberattack or malicious activity.

Three outages across five years, affecting three different subsystems, but with one thing in common: each began with a change that was not expected to cause an outage.

Fastly and Akamai: when a normal change finds a hidden bug

The summer of 2021 provided two more examples of how routine changes and latent software defects can combine.

On June 8, a single Fastly customer made a completely valid configuration change. There was nothing inherently wrong with what the customer had done.

Unfortunately, that change triggered a latent software bug introduced during a Fastly deployment on May 12.

Within seconds, approximately 85% of Fastly’s network began returning 503 errors. Amazon, Reddit, CNN, the BBC, Twitch and gov.uk were among the services affected.

Fastly restored approximately 95% of its network within about 49 minutes, according to its official incident summary.

Six weeks later, Akamai experienced a strikingly similar problem.

On July 22, a software configuration update triggered a bug in Akamai’s Secure Edge Content Delivery Network, affecting the network’s DNS system. Akamai confirmed that the incident was not a cyberattack.

PlayStation Network, Steam, Disney+ Hotstar, LastPass, major banks and airlines experienced disruption for up to an hour.

The outage ended when Akamai rolled back the update.

That detail is worth paying attention to because rollback is one of the few things an organization can directly control when a change goes wrong. Fastly recovered once the trigger had been identified, while Akamai resolved its incident by reverting the configuration.

Being able to identify and reverse a change quickly can make an enormous difference to how long an outage lasts.

There is another important detail in the Fastly incident. According to ThousandEyes, customers that had alternative providers available were able to reduce the impact.

The software bug belonged to Fastly. The dependency on Fastly did not have to.

AWS, October 2025: when DNS automation deletes its own record

The AWS outage of October 2025 shows that configuration risk does not disappear when humans are removed from the process.

Sometimes automation simply allows a problem to happen much faster and at much greater scale.

According to AWS’s post-event summary, the incident was triggered by a latent defect in DynamoDB’s automated DNS management system, which caused endpoint resolution failures.

A race condition occurred between DynamoDB’s DNS Planner and its redundant DNS Enactors. A delayed Enactor overwrote a newer DNS plan with a stale one. Cleanup automation then deleted the active plan, leaving an empty DNS record for dynamodb.us-east-1.amazonaws.com.

DynamoDB itself was perfectly healthy. The problem was that customers could no longer resolve the address required to reach it.

Neither could some of AWS’s own internal services.

That failure set off a much wider cascade. EC2 launches failed, load balancers struggled, and Lambda, STS and IAM sign-in services experienced degradation.

More than 1,000 services and roughly 70,000 organizations were affected. Snapchat, Fortnite, Roblox, Coinbase, Venmo, Ring and the UK’s HMRC were among those caught up in the disruption.

The effects of the incident continued for approximately 15 to 16 hours. One third-party analysis estimated insured losses at somewhere between $38 million and $581 million.

One of AWS’s first remediation steps was to disable the DNS Planner and Enactor automation worldwide.

The incident is a useful reminder that automation does not remove the possibility of human or software error. It simply moves the risk somewhere else in the system.

Azure DNS experienced a failure from the same broad family in April 2021. An anomalous surge in DNS queries exposed a code defect in Azure’s DNS edge caches. Client retries then amplified the load, causing Xbox Live, Office 365 and Dynamics to experience disruption for around an hour.

Once again, no attack was officially attributed to the incident.

What the numbers tell us

Looking across 13 verified major DNS-related incidents between 2015 and 2025, eight were caused by misconfiguration or change-related failures. Three involved software bugs, two of which were triggered by routine configuration changes.

Only two were attacks, and both were DDoS events from 2016.

In this set of incidents, not one of the major DNS outages since 2019 was caused by an attack.

That pattern extends beyond DNS.

According to the Uptime Institute’s 2025 Annual Outage Analysis, nearly 40% of organizations experienced a major outage caused by human error during the previous three years. Of those incidents, 85% were attributed either to staff not following procedures or to problems with the procedures themselves.

Across 25 years of data, Uptime Institute has implicated human error in between two-thirds and four-fifths of all downtime. Four out of five operators also say their most recent serious outage could have been prevented.

Then there is the cost.

ITIC’s 2024 survey found that an hour of downtime now costs more than $300,000 for over 90% of mid-size and large enterprises. Some 41% reported hourly costs ranging from $1 million to more than $5 million.

Uptime Institute’s research paints a similar picture. Fifty-four percent of operators said their most recent significant outage cost more than $100,000, while one in five said the cost exceeded $1 million.

None of this means DNS attacks should be ignored.

The IDC/EfficientIP DNS Threat Report found that most organizations face DNS attacks annually, with the average cost approaching $1 million per attack. DDoS and other malicious activity remain very real risks.

The point is that the evidence tells us not to focus on those threats alone. When we look at the incidents that have taken some of the world’s biggest services offline, routine changes, software defects and operational failures feature again and again.

The change window may be every bit as important to your risk model as the attacker.

What this means for your DNS strategy

You cannot stop an engineer at Meta from making a mistake. You cannot prevent a Cloudflare policy change from behaving unexpectedly or guarantee that AWS will never encounter another race condition.

What you can decide is how exposed your organization will be when something like that happens.

There are four practical guardrails worth considering.

1. Treat DNS changes as production incidents waiting to happen

Almost every non-attack incident above started with a routine change.

That does not mean organizations should become afraid of making changes. It means DNS needs the same change-management discipline as any other critical production system.

Your DNS control plane should maintain complete, immutable change logs showing who changed what, when it was changed and why.

When something goes wrong, “What changed?” should be a question your team can answer immediately, not the beginning of a lengthy investigation.

2. Make sure you can restore a known-good configuration quickly

Akamai ended its outage by rolling back a configuration update. Fastly recovered once the triggering change was understood.

When an outage is caused by a change, reverting that change is often the fastest route back to normal operation.

This makes rollback speed a practical part of your availability strategy.

If restoring the last known-good DNS state requires a support ticket, a lengthy manual process or someone trying to reconstruct the old configuration, recovery is already taking longer than it should.

This is where capabilities such as DNS change logs and one-click restore become important. They are not simply administrative conveniences. They directly affect how quickly a team can recover from a bad change.

3. Use a multi-provider DNS strategy

Running DNS across independent providers is one of the most proven ways to reduce provider concentration risk.

The Dyn attack in 2016 drove a wave of enterprise interest in dual-provider DNS. Fastly customers with alternative providers were able to minimize the impact of its 2021 outage. IBM NS1 Connect also credited multi-CDN DNS steering with helping it remain available through Cloudflare’s November 2025 outage.

GitLab provides the opposite example. It went completely dark during Cloudflare incidents in both 2020 and 2022 because it relied on a single DNS/CDN provider.

With two independent and synchronized DNS providers, a failure or bad change at one provider does not automatically have to become your outage.

This is the principle behind a multi-provider DNS strategy. The objective is not to find a provider that will never fail. No provider can credibly promise that. The objective is to remove the assumption that one provider must always be available for your business to stay online.

4. Do not overlook the registrar

DNS resilience also depends on maintaining control of the domain itself.

In July 2024, the Squarespace and Google Domains migration exposed another form of configuration risk. MFA was silently disabled in some cases and unverified account creation was possible, allowing attackers to hijack dozens of domains and redirect DNS to phishing sites.

Weak defaults can be a form of misconfiguration too.

Registry locks, MFA and EPP clientUpdateProhibited controls should therefore be considered part of DNS resilience, not simply routine security hygiene.

The biggest risk may be more ordinary than you think

The biggest DNS outages in history have not all started with extraordinary events. Many started on an ordinary working day with a maintenance command, a permissions change, a valid customer configuration or a race condition that nobody knew was there.

That is what makes these incidents so useful.

They show us that protecting DNS is not only about defending against attackers. It is also about accepting that people make mistakes, software contains bugs, automation can behave unexpectedly and even the largest infrastructure providers sometimes get things wrong.

A sensible DNS risk model needs to account for all of those possibilities.

Change logs give teams visibility into what happened. Fast rollback gives them a way back. Independent secondary DNS reduces the consequences when a provider fails. Strong registrar controls help ensure that control of the domain itself is protected.

These guardrails are relatively inexpensive compared with the cost of an outage, which can range from hundreds of thousands to millions of dollars per hour.

At Total Uptime, this is exactly the problem our DNS platform is built to address. It provides fully versioned DNS change logs with one-click restoration to any previous state, native multi-provider and secondary DNS support, and an independent anycast network designed to keep applications reachable when another provider experiences an outage or a routine change goes wrong.

Because the question is not whether somebody, somewhere in your application delivery chain will eventually make a mistake.

The more useful question is whether your business has to go offline when they do