Blog

12 weirdest root causes in internet history

July 17, 2026
Rohan T
5 Mins
Gray upward-pointing arrow icon.
Click To Explore

Table of contents

Downward-pointing chevron dropdown arrow icon in black.
Score: 0 right · 0 of 12 solved

The incidents

Ranked roughly by how hard the root cause would be to say out loud in the review meeting.

SEV-1 INC-2017-0228 Amazon Web Services

1. Half the internet goes down. The status page stays green.

The symptom

February 28, 2017. Amazon's cloud storage service — the one quietly holding files for a huge chunk of the internet — breaks for four hours. Slack uploads die. Trello dies. Smart lightbulbs stop listening to their owners.

Best detail: Amazon's own status dashboard showed green the entire time. The dashboard's icons were stored on the thing that was down.

Take your guess — what caused it?
What actually happened

An engineer was following an approved, step-by-step playbook to take a few servers offline for debugging. One value in the command was mistyped, and the tooling cheerfully removed a far bigger set of servers than intended — including ones running two core systems that hadn't been fully restarted in years. They needed a long, careful cold start, and the internet got a four-hour nap.

An authorized human. An approved playbook. One wrong keystroke.

Steal this lesson

If one typo can take out a thousand times more than you intended, the typo isn't the problem — the missing guardrail is. Cap how much any single command can remove. And never host your status page on the thing it's supposed to report on.

Deep dive: AWS's official incident summary →
SEV-1 INC-2012-0801 Knight Capital, Wall Street

2. The dead code that woke up and spent $440 million before coffee

The symptom

August 1, 2012, 9:30 AM. The moment the stock market opens, one of Wall Street's biggest trading firms starts firing millions of orders nobody asked for. By 10:15 it has lost about $440 million — more than it had in the bank. Within a week, the company effectively no longer exists on its own.

Take your guess — what caused it?
What actually happened

Technicians rolled out new trading software to seven of their eight servers. The eighth was missed. Worse, the release reused an old on/off switch that used to activate Power Peg — a retired test routine built years earlier to deliberately buy high and sell low, purely to stress-test the system. It was never deleted. Just left there, sleeping.

The switch flipped on. Seven servers ran the new code. The eighth heard the old signal, woke the zombie, and did precisely what it was designed to do: lose money as fast as possible — with real capital, at market speed.

Steal this lesson

Delete dead code. Not commented out, not hidden behind a switch — gone. And treat "deployed to 7 of 8 servers" as a failed deploy, because that's exactly what it is.

Deep dive: “Knightmare” — the definitive breakdown →
SEV-1 INC-2017-0131 GitLab.com

3. 300 GB deleted, five backups checked, five backups broken

The symptom

January 31, 2017. GitLab.com — where thousands of teams keep their code and projects — goes down hard. About 300 GB of live production data is gone: issues, comments, merge requests. Then the team discovers, in real time, that all five of their backup systems had been quietly failing for a while.

To their eternal credit, they live-streamed the entire recovery on YouTube while thousands watched.

Take your guess — what caused it?
What actually happened

Late at night, a tired engineer was fighting a lagging database copy. The fix: wipe the backup server's data folder so it could re-sync fresh. He ran the delete command. In the terminal window connected to the main server. He noticed within seconds. Seconds were plenty.

The data came back thanks to a manual snapshot another engineer happened to take six hours earlier — pure luck. The scheduled backups? Failing silently. The cloud copies? Empty folder. The emails warning about all this? Bounced.

Steal this lesson

A backup you've never restored is a rumor. Test restores on a schedule, page someone when backups fail, and make production terminals impossible to mistake — red prompt, giant hostname, whatever it takes at 11 PM.

Deep dive: GitLab's brutally honest post-mortem →
SEV-1 INC-1998-TS2 Pixar Animation Studios

4. The day Toy Story 2 got deleted (and maternity leave saved it)

The symptom

1998. Pixar animators watch their film vanish in front of them. Woody's hat disappears. Then his boots. Then Woody. Then whole scenes. Roughly 90% of two years of work evaporates from the servers in minutes.

Then discovery number two: the backups had been silently broken for about a month.

Take your guess — what caused it?
What actually happened

Someone ran rm -rf * — the delete-everything-below-this-point command — against the master folder holding the movie. The computer did what computers do: exactly what it was told, without a single follow-up question.

The film survived because technical director Galyn Susman had recently had a baby and was working from home, with a full copy of the movie syncing to a machine in her house. Pixar drove that computer back to the studio wrapped in blankets, buckled in like a passenger. A home desktop was, functionally, the studio's only off-site copy.

Steal this lesson

Run actual restore drills, put guardrails on delete commands aimed at shared storage, and accept a hard truth: your disaster plan is only as good as the last time you tested it. "An employee's home PC" should not be the plan.

Deep dive: the full story, from Pixar's own CTO →
SEV-1 INC-2012-0229 Microsoft Azure, global

5. The outage that was scheduled four years in advance — by the calendar

The symptom

February 29, 2012. Microsoft's cloud starts dying worldwide just before midnight and stays wobbly for over a day. Government services go down with it. Nothing was deployed. No hardware failed. As far as anyone could tell, the trigger was the date itself.

Take your guess — what caused it?
What actually happened

Deep inside Azure, a piece of software created security certificates valid for exactly one year — calculated by taking today's date and adding 1 to the year. On February 29, 2012, that math produced February 29, 2013. A date that does not exist. Certificate creation failed, the software mistook its own bug for broken hardware, marked healthy machines as faulty, and the platform's self-healing systems started taking down perfectly good servers at scale.

One line of date math, asleep for four years, waiting for its moment.

Steal this lesson

Never do calendar math by hand — use a proper date library that already knows about leap years. And watch out for self-healing systems with the wrong diagnosis: automation that fixes the wrong problem is just automated demolition.

Deep dive: Microsoft's engineering write-up →
SEV-1 INC-2019-0702 Cloudflare, global

6. 27 minutes where one text-matching rule ate every CPU on Earth (well, theirs)

The symptom

July 2, 2019. A huge slice of the web starts throwing error pages at once. Cloudflare — the company that sits in front of millions of websites to keep them fast and safe — watches every processor across its worldwide network hit 100% at the same moment. It looks exactly like the biggest attack in history. It isn't.

Take your guess — what caused it?
What actually happened

A new firewall rule shipped with a text-matching pattern that had a nasty property: on certain inputs, the work it needed exploded instead of finishing. Every processor that touched it got stuck grinding on the same impossible task. And because security rules were built to deploy worldwide in seconds (to react to attacks fast), every machine on the planet received the poisoned rule at once.

One pattern. Written by one person. Reviewed and approved. Down went the network built to keep the internet up — for 27 very long minutes.

Steal this lesson

Anything that ships everywhere in seconds needs a small test group first — yes, even "just a config change." And treat matching patterns like real code: test them against hostile input and give them a hard limit on how long they can run.

Deep dive: Cloudflare's minute-by-minute account →
SEV-1 INC-2020-1214 Google, global

7. The day Google logged out planet Earth

The symptom

December 14, 2020. Gmail, YouTube, Docs, Calendar and Meet all throw errors worldwide for about 45 minutes. People can't turn on their lights because the smart-home app can't sign them in. Anything that needs a Google login fails. Everywhere. At once.

Take your guess — what caused it?
What actually happened

An automated system that hands out storage allowances had a bug: it decided Google's central sign-in service was using zero storage, and helpfully shrank its allowance to match. When the grace period ran out, the service that verifies every Google login on Earth had no room left to write. It couldn't record new sessions, so it did the only thing it could: reject everyone.

The oldest failure in computing — disk full — wearing a very modern automation costume.

Steal this lesson

Give automation sanity checks. A system that "notices" your login service using zero storage should wake up a human, not act on it. Your sign-in layer deserves generous, untouchable headroom — everything else depends on it.

Deep dive: Google's official incident report →
SEV-1 INC-2021-1004 Facebook / Meta, global

8. Facebook erases itself from the internet, then can't open its own doors

The symptom

October 4, 2021. Facebook, Instagram and WhatsApp vanish for about six hours. Not slow. Not glitchy. Gone — the rest of the internet simply no longer knows where to find them. 3.5 billion people's apps go dark, and everyone floods Twitter to ask if it's just them.

Take your guess — what caused it?
What actually happened

A routine maintenance command, meant to check spare capacity on Facebook's internal backbone, instead disconnected all of its data centers from each other. A safety mechanism then noticed the disconnect and did what it was designed to do: pull Facebook's addresses off the internet's global map. From the outside, Facebook had simply stopped existing.

The kicker: internal tools, email — even the badge readers on the data center doors — ran on the same downed network. Engineers had to physically drive to the buildings and fight their way in to reach the machines, because the systems they needed to fix were the systems they needed in order to fix them.

Steal this lesson

You need a back door that doesn't depend on the front door. Emergency access — network, chat, and yes, physical locks — must survive the outage it exists to fix. Map your circular dependencies before an outage maps them for you.

Deep dive: Meta's own engineering account →
SEV-1 INC-2008-0224 YouTube, global

9. One ISP tries to block YouTube at home — and hijacks it for the whole planet

The symptom

February 24, 2008. YouTube disappears for most of the world for around two hours. Its servers are fine. Nothing crashed. But all of YouTube's traffic is now flowing to a network in Pakistan and dying there — because the internet has collectively decided, all at once, that YouTube moved.

Take your guess — what caused it?
What actually happened

The Pakistani government ordered local providers to block YouTube inside the country. One telecom implemented the block by publishing a fake set of directions: "YouTube lives over here now" — pointing at a dead end. Those directions were meant to stay domestic. They leaked to the wider internet, and because the internet's routing system trusts the most specific directions it hears, the entire world obediently rerouted YouTube's traffic into the void.

The internet's routing layer runs on trust between networks. In 2008, nothing stopped one mid-sized provider from accidentally redirecting a global platform.

Steal this lesson

Your uptime partly depends on router settings in companies you've never heard of. Use route protections that verify who owns which addresses, and monitor how the internet sees you from the outside — not just how you see yourself.

Deep dive: the RIPE NCC hijack analysis →
SEV-3 INC-199X-UNC University campus mail

10. "We can't send email more than 500 miles"

The symptom

A statistics department chairman calls his sysadmin with the greatest support ticket ever filed: emails to anyone within about 500 miles deliver fine, while anything farther fails. Being statisticians, they've tested it properly. There's a map. Raleigh works; Seattle doesn't. The sysadmin explains that email cannot possibly work that way. The map disagrees.

Take your guess — what caused it?
What actually happened

A server update had quietly rolled the mail software back to an older version — which then read a settings file written for the newer one. Options it didn't understand, it ignored. One of those was the connection timeout, which ended up effectively at zero: a few milliseconds in practice.

A connection could only succeed if the other server answered almost instantly. And light traveling through fiber covers about 3 milliseconds' worth of distance — just over 500 miles. Anything farther away physically couldn't answer in time. The users' impossible bug report was accurate to within a rounding error of the laws of physics.

Steal this lesson

Settings drift silently, and the results get weird. Check that your software versions and their settings actually match. And when users report something impossible, measure before you dismiss — sometimes the impossible checks out.

Deep dive: the original story, told by the sysadmin himself →
SEV-1 INC-2011-0328 Armenia, nationwide

11. A 75-year-old with a spade takes an entire country offline

The symptom

March 2011. Armenia — a country of about 3 million people — loses roughly 90% of its internet for up to 12 hours. Parts of two neighboring countries flicker too. No attack. No data center fire. Just an entire nation refreshing pages that will not load.

Take your guess — what caused it?
What actually happened

A 75-year-old woman in neighboring Georgia was digging for scrap copper to sell. Her spade found a buried fiber-optic cable — the main line carrying most of Armenia's connectivity — and cut clean through it. The press nicknamed her "the spade hacker." She reportedly had no idea what the internet was. She remains its most efficient adversary.

Steal this lesson

Every cloud, every promise of "always on," ultimately rests on glass buried in dirt. If your region's traffic funnels through one trench, one spade is your single point of failure. Ask providers about physically separate paths, not just logical backups.

Deep dive: The Guardian's report on the spade hacker →
SEV-2 INC-2016-0429 CERN, Large Hadron Collider

12. Humanity's greatest machine vs. one hungry weasel

The symptom

April 29, 2016. The Large Hadron Collider — a $7 billion, 17-mile machine built to probe the structure of the universe — suffers what the official log calls a "severe electrical perturbation" and shuts down for days, right as it was gearing up for new discoveries. The lab's own weekly status note reads: "Not the best week for the LHC!"

Take your guess — what caused it?
What actually happened

A stone marten — a member of the weasel family — climbed onto a 66,000-volt transformer and bit a cable. The official incident log records the cause, in French, as "short circuit caused by fouine." The marten did not survive its contribution to particle physics. Its taxidermied body is now on display at the Rotterdam Natural History Museum, in an exhibit devoted to animals that collided with human infrastructure.

It wasn't even the collider's first wildlife incident. In 2009, a passing bird knocked out part of the cooling system by dropping a baguette on outdoor electrical equipment. The machine that recreates the birth of the universe has now been defeated by both a weasel and French bread.

Steal this lesson

Your risk register needs a "nature" column. Animals cause a startling share of real outages (see below), and no amount of clever software protects a transformer from teeth.

Deep dive: NPR on the weasel that stopped physics →

Honorable mentions: the wildlife division

The animal kingdom deserves its own incident review. Tap to expand.

Level 3, a major internet backbone company, reported that squirrels caused 17% of its cable outages in a single year. One frying squirrel took out half of Yahoo's Santa Clara data center. A former NSA deputy director called squirrels the number-one threat to the US power grid. A satirical tracker, CyberSquirrel1, logged their attacks as classified war operations.

A squirrel caused a power failure in Trumbull, Connecticut — home of NASDAQ's computer center — shutting down the exchange and disrupting some twenty million trades. Wall Street, briefly brought to you by one rodent's final mistake.

Sharks have been filmed biting the undersea cables that carry the internet between continents, possibly drawn to their electromagnetic fields. Google ended up reinforcing sections of its trans-Pacific cables with a Kevlar-like wrap. Somewhere in your cloud provider's risk planning, there is a line item for shark-proofing.

Swarms of jellyfish have repeatedly forced power stations — including nuclear plants — to throttle down by clogging their seawater cooling intakes. The grid, it turns out, has a marine-biology dependency nobody put on the architecture diagram.

Australia's national broadband network found cockatoos persistently chewing through cables on its wireless towers, racking up repeated damage and repair bills. As far as anyone can tell, the birds do it for fun.

What the hall of fame actually teaches

Read enough of these and a pattern shows up. Almost none of these disasters started big. They started tiny — a typo, a forgotten switch, a chewed cable — and became famous because of what happened next: nothing limited the damage, the backups turned out to be fiction, the status page lied, the door locks ran on the network that was down, the warning emails bounced.

That second layer is the part you control. You can't stop a weasel from finding your transformer, and someone on your team will eventually type the right command into the wrong window. What separates a five-minute blip from a company-ending headline is everything wrapped around the mistake: how fast the right people find out, how quickly noise turns into a clear signal, how smoothly the response runs, and whether the review afterward actually changes anything.

That's the whole job of incident management. The root causes will keep being ridiculous. Your response doesn't have to be.

Book a Demo →