10 Disasters Caused by a Single Point of Failure

Some catastrophes unfold slowly, with warning signs ignored for years. Others happen in an instant—triggered by one tiny flaw in a vast, complex system. These are the disasters that didn’t require sabotage, invasion, or neglect—just a single line of bad code, a misread sensor, or one overlooked spreadsheet limit. In each case, billions of dollars, lives, or national reputations depended on just one thing working as it was supposed to.

These are 10 times that one thing didn’t.

Related: 10 Recent Tech Fails and Disasters

10 The Mars Climate Orbiter’s Metric Mishap (1999)

NASA’s Mars Climate Orbiter was part of a two-satellite mission to study the Martian climate and surface changes. The spacecraft launched smoothly and performed well until it prepared to enter Martian orbit. That’s when it veered too close to the planet, burned up in the atmosphere, and disappeared forever. The cause was deceptively simple: Lockheed Martin had delivered thruster performance data in pound-seconds, but NASA engineers interpreted that data as newton-seconds. Over months, that minor unit mismatch became a 106-mile (170-kilometer) trajectory error.

The mission team noticed inconsistencies in navigational data but attributed them to benign modeling differences. A software handoff checklist failed to clarify units. There was no unified code repository or system-level data validation. The loss exposed how fragile space missions can be when different contractors use inconsistent standards. A single conversion—one multiplication factor that never happened—was enough to vaporize a $125 million mission built over years by hundreds of engineers.^[1]

9 One Expired Certificate Crashes Facebook, Instagram & WhatsApp (2021)

On October 4, 2021, billions of users found that they couldn’t refresh Facebook, send a WhatsApp message, or even log into their Oculus headsets. Internally, Facebook engineers couldn’t communicate via company tools or even use their ID badges to enter buildings. The root cause was a misconfiguration during routine maintenance that triggered the withdrawal of Facebook’s BGP (Border Gateway Protocol) routes, effectively removing Facebook’s presence from the global internet. DNS servers couldn’t be found, and without DNS, every Facebook-owned service—Messenger, Instagram, Workplace—was unreachable.

However, the disaster got worse because access systems were tied to the same infrastructure. Engineers couldn’t reach the servers that could restore access because the very tools needed to diagnose the issue were offline. There was no independent failover for physical access or out-of-band recovery for DNS updates. The company had built a high-speed global network optimized for internal control—but no longer had a reliable path back into its own brain when something went wrong.^[2]

8 The Great Northeast Blackout (2003)

On August 14, 2003, power plants across the U.S. Northeast and parts of Canada went dark, affecting 55 million people. The blackout began with a single overgrown tree in Ohio, which brushed against a transmission line and caused it to shut down. Normally, the grid compensates by rerouting power, but the monitoring software at FirstEnergy failed to alert operators that the grid was becoming unstable. Overloaded lines began to sag into other trees and shut down one by one. The blackout spread from Michigan to New York City in under two hours.

It wasn’t just electricity that failed—sewage systems, water treatment plants, airports, traffic lights, and subways stopped functioning. Cities like Cleveland lost water pressure. Toronto was paralyzed. New York had to evacuate subway tunnels in the dark. While the grid was built with redundancies, they all relied on real-time operator feedback. That one broken alert system—an overlooked point of failure in the human-machine loop—allowed a preventable event to grow into the worst blackout in North American history.^[3]

7 TSB’s Botched IT Migration (2018)

When UK bank TSB separated from its parent company, Lloyds Banking Group, it planned to migrate 1.3 billion records to a new IT system managed by its Spanish owner, Sabadell. The bank shut down systems over a weekend and began the cutover. But when services came back online, chaos erupted. Customers found zeroed balances, vanished payments, locked accounts, and, in some cases, access to other people’s data. Branch queues spilled into the streets, and phone support collapsed under the surge.

The underlying issue was a mismatch between how legacy data fields were structured and how the new platform interpreted them—a flawed data mapping logic buried deep in the migration script. The system passed internal pre-tests, but those didn’t simulate full live loads or edge-case behaviors. Once errors surfaced, recovery was hampered by a lack of rollback options and incomplete audit logs. The bank had tied its entire digital identity to one brittle transfer, and when it cracked, so did customer trust, investor confidence, and regulatory goodwill.^[4]

6 Amazon’s S3 Outage from a Typo (2017)

Amazon Web Services S3 (Simple Storage Service) is used by millions of businesses to store images, files, and backend web services. In February 2017, a technician attempting to debug the billing system issued a command intended to remove a small number of servers—but instead, the script accidentally removed a much larger set, including a critical index server for the entire S3 system in the U.S. East 1 region. That one deletion wiped out access to location data and metadata for S3 objects across hundreds of major sites.

Trello, Slack, Netflix, Giphy, Medium, and even parts of AWS’s own Service Health Dashboard went dark. Monitoring tools failed because they themselves relied on S3. Customers couldn’t even check the AWS status page to determine what was wrong. AWS had built robust infrastructure with redundancy across zones—but not within the core control plane, which had no safeguards against operator error. That one misfired internal command—typed into a terminal with root access—collapsed a chunk of the internet for four hours.^[5]

5 One Spreadsheet Cell That Sank a Billion-Dollar Trading Firm (2012)

Knight Capital Group was a major player in U.S. equity markets, responsible for about 10% of all trading volume at the time. In August 2012, the firm deployed a new trading algorithm, but an old, unused software flag was mistakenly reactivated in live code. This happened because engineers repurposed legacy code modules and didn’t properly disable a testing feature called “Power Peg,” which began sending erroneous stock orders at lightning speed across dozens of exchanges. In just 45 minutes, Knight burned through $440 million in losses, triggering massive price fluctuations in 148 stocks.

The cause? A single variable in a spreadsheet-like configuration file that wasn’t updated correctly on one out of eight servers. That one machine kept broadcasting aggressive buy orders without limit. Other systems couldn’t recognize it as faulty because it wasn’t crashing—just functioning catastrophically wrong. The firm didn’t have a kill switch for runaway trades and couldn’t override the logic quickly enough. By the time they pulled the plug, Knight had wiped out a third of its market value and effectively sealed its fate as an independent firm.^[6]

4 Toyota’s Unintended Acceleration Scandal (2009–2010)

In late 2009, Toyota vehicles began being linked to a series of crashes caused by unintended acceleration. Initially blamed on floor mats and sticky pedals, the deeper cause emerged in some models: a flaw in the electronic throttle control system that could, under certain electrical conditions, lock the accelerator open without a clear override for the driver. There was no mechanical linkage anymore—brake overrides were inconsistent across models, and redundant fail-safes were not universally implemented.

The most chilling example was a tragic 911 call made by an off-duty highway patrolman in California whose Lexus accelerated uncontrollably and crashed, killing four people. Investigations revealed that Toyota engineers had been ignoring or downplaying software risks for years, and the company had previously settled similar complaints quietly. When NASA analyzed the codebase, they found it was poorly structured, difficult to test, and lacked robust redundancy. The electronic system’s vulnerability was baked into the architecture, meaning the failure of just one sensor signal or logic path could lead to fatal acceleration.^[7]

3 A Miswired Sensor That Brought Down a Jet (2009)

Air France Flight 447 vanished over the Atlantic in 2009 en route from Rio to Paris. In the investigation that followed, black box data revealed that the jet’s pitot tubes, small sensors used to measure airspeed, had iced over during a thunderstorm. This triggered conflicting data that caused the autopilot to disengage. The pilots, unsure of their actual speed and altitude, responded by pulling the nose up, mistakenly believing the plane descended too fast. They stalled the aircraft at 38,000 feet and never recovered.

The Airbus A330 had multiple systems in place to handle equipment failure, but those systems relied on clean sensor input. When the three pitot tubes iced up simultaneously, the redundancy collapsed. More critically, the pilots weren’t adequately trained for this type of high-altitude stall, especially one triggered by contradictory flight data. At that moment, the plane’s fate depended on how well three small tubes could function in cold weather. They didn’t—and 228 lives were lost because there was no meaningful backup plan.^[8]

2 A Bad Excel Formula That Hid a Pandemic (2020)

In September 2020, Public Health England used Microsoft Excel to track COVID-19 test results, importing daily updates from labs into a central spreadsheet. However, the spreadsheet was saved in the outdated .XLS format, with a hard limit of 65,536 rows. Once that number was exceeded, new test results were silently dropped—meaning nearly 16,000 positive cases were never forwarded to contact tracers. For days, potentially infected individuals walked around unaware, spreading the virus further while local health officials worked with incomplete data.

The problem wasn’t a broken test, a cyberattack, or a failed server—it was an outdated file format still being used in a national crisis. The team responsible had no automated alerts when data was being lost, and the system wasn’t reviewed by IT professionals before deployment. In the end, the country’s pandemic response was kneecapped by a software limit that had been publicly documented since 1987, and no one checked whether it applied to their use case.^[9]

1 Challenger Disaster’s O-Ring Catastrophe (1986)

The Space Shuttle Challenger broke apart 73 seconds after launch, killing all seven astronauts aboard. The disaster was caused by the failure of an O-ring seal on one of the solid rocket boosters. Temperatures that morning were unusually cold—below the O-ring’s tested tolerance—and engineers at contractor Morton Thiokol warned that the rubber could stiffen and fail to properly seal the joint. NASA, under pressure to maintain its launch schedule and facing a televised schoolroom mission, overrode the warning and proceeded anyway.

When the shuttle launched, the O-ring on the right booster failed to expand quickly enough to seal the hot gases inside. Flames escaped, ignited the external fuel tank, and destroyed the shuttle in front of a live national audience. Investigations revealed that the O-ring issue was already known internally, with engineers flagging it in prior memos. The entire vehicle’s safety had been allowed to rest on the performance of a rubber seal the size of a bracelet, and when that one part failed, so did the most ambitious space program on Earth.^[10]

fact checked by
Darci Heikkinen