Skip to main content

Failure analysis · Case file

The Boeing 737 MAX Failed Through Assumptions That Removed Safety Margin

Published · July 27, 2026 Updated · July 27, 2026

The 737 MAX disasters were not produced by one line of software alone. They emerged from a chain of assumptions about sensor reliability, pilot response, training and certification that left too little margin when several things went wrong together.

Why did it fail?

Lion Air Flight 610 crashed in October 2018 and Ethiopian Airlines Flight 302 crashed in March 2019, killing 346 people. In both accidents, erroneous angle-of-attack data activated the Maneuvering Characteristics Augmentation System, or MCAS, which commanded nose-down stabilizer movement.

Investigations identified technical, organizational and regulatory failures. The original MCAS design relied on data from a single angle-of-attack sensor, could activate repeatedly and was evaluated using assumptions about how quickly flight crews would diagnose and respond to the condition.

A single input carried system-level authority

A sensor can fail. Safety depends on whether the architecture detects, contains and communicates that failure before it drives a hazardous action. The Federal Aviation Administration’s review identified the use of one angle-of-attack sensor and repeated MCAS commands as issues requiring correction.

The revised design compares both sensors, limits activation and provides additional protections. Those changes illustrate the missing margin in the original system: one erroneous input should not have been able to repeatedly command a critical control surface without stronger cross-checks.

Human response was treated as a predictable component

The National Transportation Safety Board and congressional investigators challenged assumptions about pilot recognition and response. Real crews faced multiple alerts and indications, not the isolated failure condition represented in simplified assessments. Information about MCAS and training requirements also became central questions after the first crash.

When a safety case relies on people correcting automation quickly, the assessment must reproduce the confusion, workload and surprise of the actual event. A response time observed in a clean scenario is not automatically available in a cockpit filled with conflicting signals.

Commercial and certification pressures weakened challenge

A 2020 report by the U.S. House Committee on Transportation and Infrastructure described production pressure, faulty technical assumptions, lack of transparency and insufficient regulatory oversight. The MAX returned to service only after mandated software, design, maintenance and training changes.

The practical lesson

Safety-critical systems need independent layers of protection and explicit treatment of uncertainty. Challenge every single point of failure, every optimistic human-response assumption and every incentive to classify a change as smaller than it is. Compliance is a minimum condition; the design must remain safe when sensors, software and people behave less neatly than the certification scenario expects.

Sources

Our analyses distinguish documented facts from editorial interpretation. If you have evidence that changes this account, contact the editorial desk.

A different failure deserves a different explanation.

Have first-hand evidence, a correction, or a case we should investigate?

Send it to the editors