The Therac-25 was a medical linear accelerator built by Atomic Energy of Canada Limited (AECL) to treat cancer with radiation. Between June 1985 and January 1987 it administered enormous radiation overdoses to at least six patients across several hospitals in the United States and Canada, causing severe injuries and several deaths. The definitive account is “An Investigation of the Therac-25 Accidents” by Nancy G. Leveson and Clark S. Turner, published in IEEE Computer in July 1993, which remains the primary scholarly analysis of the failures.
A central design decision set the disaster in motion: where earlier Therac models used independent hardware interlocks to prevent unsafe beam configurations, the Therac-25 relied on software to enforce those safety checks. The hardware interlocks were removed, so a software fault could place the machine into a dangerous state with nothing physical to stop it. The high-energy electron beam, normally spread and attenuated by a target and flattening hardware when in X-ray mode, could under fault conditions strike a patient directly at full intensity.
Leveson and Turner identified concurrent-programming defects, including a race condition, as a key technical cause. When a skilled operator edited treatment parameters very quickly on the console, a timing window in the software allowed the machine’s actual physical setup to fall out of sync with the values the software believed were in effect. The result was a setup that the software treated as safe while the hardware was configured to deliver a massive, concentrated dose. The bug was intermittent and hard to reproduce precisely because it depended on operator speed and timing (see race-condition).
Compounding the software flaws was the machine’s behavior toward its operators. The Therac-25 frequently displayed cryptic “Malfunction” messages followed only by a number, with no explanation, and operators had grown accustomed to dismissing such messages and proceeding. In several incidents the operator pressed the key to continue after a malfunction, unknowingly re-firing an overdose. Patients reported intense burning sensations during treatment, but the machine’s dose readouts and interface gave operators no reason to believe anything catastrophic had occurred.
Leveson and Turner drew lessons far beyond the specific code defects. They emphasized that the accidents resulted from a flawed software-engineering process and inadequate safety analysis, not merely isolated coding errors: there was overconfidence in software, insufficient independent review, poor reporting and follow-up after early incidents, and a culture that assumed reused software from prior models was proven safe. The case became, and remains, a foundational example in the study of software in safety-critical systems, illustrating why safety must be engineered into the whole system and why removing hardware safeguards in favor of unverified software can be deadly.