How a Manhattan Power Room Took Down the FAA's Air Traffic Control System

A 1991 Manhattan power room failure crippled the FAA's ATC system, warning that a single point of failure in power supply can breach high-availability systems.
The article reviews a 1991 incident in which a power room failure in Manhattan caused widespread outages across the FAA's air traffic control system, a case recently rediscussed on Hacker News. It exposed the fragility of the power supply chain: a concentrated power node failed, was not quickly isolated, and spread along the power chain, disabling multiple control positions. The article analyzes "hierarchical dependency failure"—upper-layer high availability offset by weak underlying infrastructure—and notes hidden common cause failure risks between redundancy on paper and physical cabling and switching logic. It extends the lessons to modern data centers, cloud services, and AI compute clusters, stressing that reliability depends on the weakest link and must be examined from the power supply layer.
In 1991, a fault in an unremarkable power room in Manhattan, New York, unexpectedly caused widespread outages across the U.S. Federal Aviation Administration's (FAA) air traffic control system. This case was recently resurfaced on Hacker News, sparking discussion in the tech community about the resilience of critical infrastructure.
Event Recap: A Small Equipment Room Triggers a Major Outage
According to historical materials cited in the Hacker News discussion, the incident began in a power room in Manhattan that supplied electricity to FAA facilities. This power room was responsible for powering air traffic control-related equipment, and when it failed, the power interruption quickly spread to the communications and control equipment that depended on it. The FAA's air traffic control system was not a single-point structure, but this failure exposed the fragility of the power supply chain—a single power node concentrated in one physical location was enough to render multiple control positions unable to function normally.
One detail worth noting: this incident occurred in the early 1990s, when the FAA's backup mechanisms and redundancy design were far less mature than they are today. The power room failure was not quickly isolated; instead, it spread along the power chain, creating a cascading reaction.
Common Cause Failure is a key concept in reliability engineering, referring to multiple seemingly independent redundant components failing simultaneously or in succession due to the same root cause. In power systems, typical common causes include: the same utility feed line supplying both primary and backup equipment, multiple UPS units sharing the same distribution panel or battery bank, and backup generators and primary power sources located in the same physical space (such as the single power room in this article). Such failures are dangerous because they directly bypass the assumption underlying redundancy design—that failures of each backup path are independent of one another. In engineering practice, the probability of common cause failure is often reduced through physical isolation (different buildings, different incoming substations), diversified technology paths (such as combining UPS with diesel generators), and regular switching drills. In this article, the Manhattan power room failure spreading along the power chain is a typical physical manifestation of common cause failure.
Why a Single Point of Failure Could Take Down the Air Traffic Control System
Air traffic control systems have extremely high requirements for continuous power supply. Once equipment such as radar, communication radios, and flight data processors loses power, controllers cannot obtain aircraft positions or maintain contact with pilots. The Manhattan power room incident shows that even if the core computing equipment itself has backups, if redundancy on the power supply side is inadequate, the entire system remains exposed to single-point failure risk.
From a system architecture perspective, this is a typical case of "hierarchical dependency failure": the high-availability design of upper-layer applications is negated by weaknesses in the underlying infrastructure. Technical discussions on Hacker News also pointed out that many critical systems have redundancy on paper, but the actual physical cabling, distribution panels, and backup power switching logic may harbor hidden common cause failure risks.
Fault Domain refers to a set of components or service scope that may be simultaneously affected by a single failure event in a system. The core goal of fault domain partitioning is to confine the impact of a single failure to the smallest possible boundary, with common methods including physical partitioning, independent power circuits, network segmentation, and isolation switches. In the case described in this article, the Manhattan power room effectively constituted an oversized fault domain: critical equipment for multiple control positions shared the same power path, and once that path failed, the fault domain boundary covered the entire affected area. Modern data centers typically partition fault domains by rack, room module, or availability zone, and require redundant copies across fault domains. Fault domains and common cause failures are often mutually causal—an oversized fault domain means a single event can affect more components, while common cause causes fault domains that should be isolated to fail simultaneously.
Implications for Modern Infrastructure
This incident from over thirty years ago still offers lessons for today's data centers, cloud services, and critical infrastructure. Physical isolation of power paths, automated switching tests for backup power, and fault domain partitioning are all key measures for avoiding similar cascading failures. The FAA subsequently overhauled the power architecture of its air traffic control facilities, but specific details are sparse in publicly available materials.
The tech community's renewed discussion of this matter is more about treating it as a cautionary tale: a system's reliability does not depend on its most advanced components, but on its weakest link. For AI compute clusters and edge nodes that depend on electricity to operate, the same logic holds true.
N+1 redundancy and 2N architecture are two commonly used redundancy levels in power supply reliability design. N+1 means adding one backup module beyond the N modules required to meet the basic load, so the system can still operate if any single module fails, but backup capacity is limited; 2N means two completely independent systems backing each other up, each capable of carrying the full load, offering higher reliability but significantly higher cost. Beyond the number of hardware units, the effectiveness of redundancy also depends on switching logic: the switching time of static transfer switches and automatic transfer switches (ATS) must match the duration of power interruption that equipment can tolerate, and the switching action itself requires regular on-load testing; otherwise, contactor sticking or battery capacity degradation may only be discovered during a real failure. One of the lessons from the FAA incident is precisely this: redundancy on paper does not equal redundancy in practice, and the independence of redundant paths, switching reliability, and regular verification are all indispensable.
Conclusion
A single Manhattan power room bringing down the FAA's air traffic control system sounds like an accident, but it was in fact the inevitable result of missing redundancy design. The source material is limited, and the technical details of the incident and subsequent remediation measures still lack more complete public records, but the core lesson is clear: the resilience of critical systems must be examined starting from the power supply layer.
One-line Summary
A 1991 power room failure in Manhattan crippled the FAA's air traffic control system, showing that a single point of failure in power supply can breach high-availability systems.
Paragraph Summary
The article reviews a historical case in which a power room failure in Manhattan, New York, in 1991 caused widespread outages across the FAA's air traffic control system, a case recently rediscussed on Hacker News. The incident exposed the fragility of the power supply chain: after a power node concentrated in one physical location failed, it was not quickly isolated and spread along the power chain, creating a cascading reaction that left multiple control positions unable to function. The article analyzes the problem of "hierarchical dependency failure" from a system architecture perspective—the high-availability design of upper-layer applications being negated by weaknesses in the underlying infrastructure—and points out that common cause failure risks may exist between redundancy on paper and physical cabling and distribution switching logic. The article concludes by extending the lessons to modern data centers, cloud services, and AI compute clusters, emphasizing that system reliability depends on the weakest link and that the resilience of critical systems must be examined starting from the power supply layer.
Related articles

WorkBuddy Agent in Action: From AI Q&A to Automated Office Work
WorkBuddy is Tencent's AI agent desktop workbench that reads local files, operates office software, executes multi-step tasks, and runs on schedules. This article explains its core features, key differences from traditional AI tools, and use cases.

Anthropic Research: LLMs Make Formal Software Verification at Scale Possible
Anthropic Frontier Red Team research shows LLMs can generate formal proofs at the RISC-V assembly level for over 100 real open-source libraries, covering 123 OSS-Fuzz libraries and 239 entry points, totaling about 180 million lines of Rocq proofs and finding hundreds of bugs. The article analyzes specification generation, the proof pipeline, trust boundaries, and cost reduction paths.

Prompt Engineering for Beginners: From Writing Prompts to Building AI Collaboration Skills
From the four functions of prompts to the six-step prompt engineering process, this article systematically covers core concepts, business value, and three layers of limitations to help beginners build a complete cognitive framework for prompt engineering.