There are many ways a machine can fail. A toaster can burn your breakfast. A printer can chew a report five minutes before a meeting, which is rude but rarely fatal. Then there is the Therac-25, a computer-controlled radiation therapy machine that turned a trusted medical device into one of the most infamous safety disasters in software history.
Between 1985 and 1987, the Therac-25 was involved in six known massive radiation overdoses in the United States and Canada. Some patients were severely injured. Some died. The machine was built to treat cancer, yet in several cases it delivered radiation with horrifying force because the software, interface, design assumptions, and safety culture around it failed at the same time. The story is not simply “a bug killed people.” That would be too neat, and reality is rarely so tidy. The Therac-25 incident was a system failure dressed in a lab coat.
This is why the Therac-25 still appears in software engineering courses, medical device discussions, cybersecurity lectures, safety-critical system training, and ethics seminars. It is a grim reminder that when code controls physical energy, bad assumptions do not stay on a screen. They leave burns.
What Was the Therac-25?
The Therac-25 was a medical linear accelerator, often called a linac, manufactured by Atomic Energy of Canada Limited, or AECL. It was designed to deliver radiation therapy to cancer patients. In simple terms, a linear accelerator uses high-energy electrons to damage or destroy cancer cells while trying to limit harm to healthy tissue. That is a delicate job. Think of it as using a flamethrower to remove a weed from a rose garden, except the flamethrower is invisible and measured in physics.
The Therac-25 could operate in two main treatment modes. In electron beam mode, it delivered electrons directly for relatively shallow tumors. In X-ray, or photon, mode, a high-energy electron beam was aimed at a metal target to generate X-rays that could reach deeper tissue. To do that safely, the machine had to place the correct hardware in the beam path. The beam, target, filters, scanning magnets, and turntable position all had to match the selected treatment mode.
That detail matters because the accidents happened when the machine could become physically configured in an unsafe way. In some cases, a high-powered electron beam intended for X-ray production was fired without the proper target or beam-spreading equipment in place. The result was not a slightly incorrect dose. It was a massive overdose concentrated into tissue that was never meant to receive it.
The Promise That Made the Machine Attractive
The Therac-25 looked like progress. Compared with earlier radiation therapy machines, it was compact, versatile, and computer-controlled. It could perform multiple treatment types in one unit, which made it appealing to hospitals. One machine, more options, less space, faster workflow. In the language of procurement committees everywhere: “This sounds efficient.”
Earlier AECL machines, including the Therac-6 and Therac-20, used hardware interlocks and protective circuits to prevent dangerous machine states. If the wrong component was in the wrong place, physical safeguards helped stop the beam. The Therac-25 relied far more heavily on software to monitor and control safety. This decision was not made by cartoon villains in a basement. It came from confidence in computer control, cost and design pressures, and a belief that software could manage what hardware had previously blocked.
Unfortunately, confidence is not an engineering control. It is a feeling wearing a hard hat.
How the Therac-25 Accidents Happened
The six known Therac-25 accidents occurred at multiple treatment centers, including facilities in Georgia, Ontario, Washington, and Texas. The incidents did not all look identical, which made the pattern harder to recognize. Patients complained of burning sensations, shocks, unusual pain, reddening skin, swelling, and later severe radiation injuries. Operators saw cryptic error messages. Service technicians sometimes found no obvious mechanical problem. The machine would often continue treating other patients as if nothing extraordinary had happened.
The Human Clue Everyone Should Have Taken Seriously
One of the most chilling parts of the Therac-25 story is that patients often sensed something was wrong before the system acknowledged it. People described burning or electric-shock sensations during treatment. In a safer reporting culture, those complaints would have triggered immediate suspicion: stop the machine, preserve logs, analyze the event, assume harm until proven otherwise. Instead, some early warnings were dismissed or misunderstood because the machine’s display suggested little or no dose had been delivered.
That is one of the central lessons of the Therac-25: when the screen disagrees with the patient, do not automatically trust the screen. Computers are excellent at being confidently wrong. Anyone who has ever followed GPS into a parking lot shaped like regret already knows this on a smaller scale.
The Tyler, Texas Incidents
The East Texas Cancer Center cases are especially important because they exposed a software flaw tied to rapid data entry. An experienced operator could enter treatment settings, notice a mistake, quickly edit the mode selection, and start treatment. Under a specific timing sequence, the software could fail to update internal settings correctly. The display appeared acceptable, but the physical machine state did not match the intended treatment.
The key problem was not simply that an operator typed quickly. Good systems must account for skilled users. In fact, skilled users often move faster than designers expect. The Therac-25 interface and software treated a realistic workflow as an abnormal edge case. In safety-critical design, that is like building a bridge that works beautifully unless cars drive on it.
The Software Bugs Were Real, But They Were Not the Whole Story
The Therac-25 had software defects, including race-condition behavior and logic errors that allowed unsafe states under particular circumstances. A race condition occurs when the outcome of a system depends on the timing of events that are not properly controlled. In ordinary software, a race condition might make an app freeze or lose a file. In the Therac-25, timing errors could affect whether a patient received a therapeutic dose or a catastrophic overdose.
One flaw involved how the machine handled quick edits to treatment parameters. Another involved a software variable that could overflow and bypass a safety check. These details are technical, but the broader problem is easy to understand: the software had too much authority and too little independent supervision.
The tragedy was not only that the code had bugs. All nontrivial software has bugs. The tragedy was that the system was designed as though the software would not fail in dangerous ways. There were too few independent hardware backups, too little meaningful error communication, insufficient testing of realistic user behavior, weak documentation, and a delayed recognition of the true hazard.
Why Removing Hardware Interlocks Was So Dangerous
Hardware interlocks are physical or electrical safeguards that prevent a machine from entering unsafe states. In radiation therapy equipment, they can help ensure that the beam cannot fire unless the correct shielding, target, filters, or positioning components are in place. They are the engineering equivalent of a stubborn bouncer who refuses to let chaos into the club.
The Therac-25’s predecessors had more independent hardware safety mechanisms. The Therac-25 shifted more safety responsibility to software. That made the machine cleaner and more modern in concept, but it also reduced defense in depth. When software became confused, there were fewer independent barriers left to stop the beam.
Defense in depth is a boring phrase until you need it. Then it becomes the most beautiful phrase in engineering. A safe system does not ask one layer to be perfect. It assumes layers will fail and makes sure another layer catches the failure before someone gets hurt.
The Error Messages Were Almost Useless
The Therac-25 sometimes displayed vague malfunction codes, such as numbered errors that operators could not interpret in a clinically meaningful way. Some errors paused treatment rather than shutting down the machine completely. Operators, accustomed to minor interruptions, could resume treatment without understanding that the machine might have entered a dangerous condition.
This is a user experience failure with life-and-death consequences. An error message in a safety-critical system must not be a riddle. “Malfunction 54” is not a safety message; it is a fortune cookie written by a lawyer. A useful warning should tell the operator what happened, why it matters, what to do next, and whether the patient may be at risk.
Good interface design is not decoration. In medical devices, aviation, industrial control systems, and autonomous vehicles, interface clarity is a safety feature. Buttons, prompts, alarms, and logs are part of the protection system. If operators cannot understand the machine, the machine is not safe enough.
Testing Failed to Imagine Real Use
The Therac-25 case also shows the danger of testing a system only under ideal or expected conditions. The machine needed to be tested under realistic clinical workflows, including fast corrections, repeated interruptions, unusual sequences, confusing messages, and operator recovery from mistakes. Real people do not interact with machines like calm robots in a training video. They hurry, correct typos, respond to interruptions, and develop habits around common warnings.
Testing should have asked uncomfortable questions. What happens if an experienced operator edits mode selection quickly? What if the display says one thing but the turntable is elsewhere? What if a sensor fails? What if an error occurs repeatedly? What if the patient reports pain during treatment? What if the software and hardware disagree?
The best safety tests are a little rude. They poke, interrupt, confuse, rush, and stress the system because reality will do the same thing later, and reality does not sign nondisclosure agreements.
Reused Software Was Treated Too Kindly
Parts of the Therac-25 software had roots in earlier machines. Reuse can be useful, but reused code is not automatically safe code. Code that behaves acceptably in one system may become dangerous in another if the surrounding hardware, assumptions, timing, sensors, or safeguards change.
The Therac-20 may have shared related software problems, but its hardware interlocks helped prevent injuries. In other words, older hardware may have been quietly catching software mistakes. When the Therac-25 removed or reduced those independent protections, latent software defects had a clearer path to the patient.
This lesson still matters. Modern teams reuse libraries, machine learning models, firmware modules, cloud components, and open-source packages every day. Reuse is not a safety argument. It is a starting point for new hazard analysis.
The Organizational Failure Behind the Technical Failure
Therac-25 was not only a software engineering disaster. It was an organizational disaster. Early accident reports were not connected quickly enough. Manufacturer responses were too confident. Users were reassured that certain failures were impossible. The software was not independently reviewed with enough rigor. The safety analysis did not sufficiently treat software as a potential source of catastrophic failure.
When organizations believe a serious accident is impossible, evidence has to fight its way uphill. That is dangerous because safety depends on humility. The correct response to a severe anomaly is not “our system cannot do that.” It is “our system may have done that, and we need to find out how before it happens again.”
The Therac-25 shows how accountability can become blurry. Designers, programmers, managers, hospitals, operators, regulators, service technicians, and documentation teams all touched pieces of the system. When many hands are involved, each person may feel responsible for only a small part. But patients experience the whole system at once.
Regulatory Response and Corrective Action
After further investigation and pressure from regulators, the Therac-25 units were eventually shut down until effective corrective actions were made. The final corrective action plan included software fixes, improved documentation, clearer warnings, and the addition of independent hardware safety mechanisms. The settlements that followed were handled out of court, but the public lesson became permanent.
The Therac-25 helped shape modern thinking about medical device software, risk management, and safety-critical development. Today, medical device software is expected to be developed with far more disciplined life-cycle processes, documentation, verification, validation, risk analysis, post-market monitoring, and human factors engineering. Standards and guidance have evolved because the industry learned, sometimes painfully, that software is not an accessory. It is part of the medical device.
What the Therac-25 Teaches Modern Software Teams
The Therac-25 is often discussed as a historical software bug, but its lessons are painfully current. We now put software in cars, pacemakers, infusion pumps, aircraft, factories, home security systems, surgical robots, and AI-assisted medical workflows. The stakes have expanded. The same old temptations remain.
Lesson 1: Never Trust Software Alone With Hazardous Energy
If software controls radiation, motion, heat, pressure, electricity, medication, or anything else that can hurt a person, it needs independent safeguards. Software can be part of safety, but it should not be the only safety net. A good design assumes that code can fail, sensors can lie, users can make mistakes, and documentation can be misunderstood.
Lesson 2: Error Messages Must Be Actionable
Safety-critical warnings should not be cryptic. They should be specific, urgent, and tied to safe action. Operators need to know whether to retry, stop, call service, remove the patient, preserve evidence, or escalate immediately. A vague code is not enough when the cost of confusion is injury.
Lesson 3: Fast Users Are Not Bad Users
The Tyler incidents showed that experienced operators could trigger unsafe behavior by entering and correcting data quickly. That does not make the operator the root cause. It means the system failed to handle normal expert behavior. Human factors engineering must study how people actually work, not how a manual imagines they work after a good night’s sleep and three cups of responsible coffee.
Lesson 4: Testing Must Include Weird Sequences
The dangerous path is often not the obvious one. It may be a quick edit, a repeated warning, a timing window, a sensor mismatch, or a rare combination of states. Safety testing must include boundary conditions, stress conditions, invalid sequences, and recovery paths. “Works on the happy path” is not a safety case.
Lesson 5: Patient Complaints Are Data
In the Therac-25 accidents, patient symptoms were critical clues. A patient saying “that burned” during radiation treatment should carry more weight than a display claiming the dose was small. In medicine, user feedback is not just a support ticket. It may be the earliest alarm.
Why the Therac-25 Still Matters in the Age of AI
The Therac-25 story feels newly relevant because software is now making or assisting decisions that affect diagnosis, treatment, triage, medication, transportation, hiring, finance, and infrastructure. Artificial intelligence adds another layer of complexity because some systems behave probabilistically and are difficult to explain. The old lesson still applies: do not place blind trust in automation just because it looks sophisticated.
AI systems can produce confident outputs that are wrong. Medical algorithms can perform differently across populations. Automated tools can hide uncertainty behind clean dashboards. Hospitals and companies can become dependent on systems they do not fully understand. That does not mean technology is bad. Radiation therapy itself saves lives. Software saves lives. Automation saves lives. But only when wrapped in disciplined design, oversight, monitoring, and humility.
The Therac-25 did not prove that computers should stay out of medicine. It proved that computers in medicine must be treated as powerful clinical actors, not magical calculators.
Experiences and Reflections: Living With Machines That Can Hurt Us
One experience that anyone can take from the Therac-25 is the uncomfortable feeling of realizing how much trust we place in machines we cannot personally inspect. Most patients do not understand the internal logic of a radiation therapy machine. Most drivers do not understand every line of software in their cars. Most hospital staff cannot audit firmware before using a device. Modern life runs on delegated trust. We trust manufacturers, regulators, engineers, clinicians, technicians, and quality systems to do their jobs before we ever enter the room.
The Therac-25 teaches that trust must be earned through process, not assumed through reputation. A polished machine with a professional interface can still contain dangerous design flaws. A confident manufacturer can still be wrong. A quiet treatment room can still hide a hazard. That is not a reason to panic. It is a reason to build systems that welcome doubt.
For engineers, the experience-related lesson is personal: your work may touch someone you will never meet. A variable name, an error handler, a timing assumption, or a skipped review can travel far beyond the office. It may land in a hospital, a car, a factory, or a child’s medical device. That reality should not paralyze developers, but it should make them allergic to sloppy confidence. “It probably works” is acceptable for a weekend weather widget. It is not acceptable for a beam of radiation.
For healthcare organizations, the Therac-25 experience highlights the importance of listening to frontline workers. Operators are often the first to notice patterns: a strange alarm, a repeated reset, a patient reaction, a workflow that feels awkward. Their observations should move quickly through a safety reporting system that does not punish people for raising concerns. A culture that silences operators is basically unplugging its smoke detectors because the beeping is annoying.
For patients, the lesson is not to fear every machine. The lesson is to speak up. If something feels wrong during a treatment, scan, infusion, or procedure, say so clearly. Ask staff to stop if you are in pain or feel an unusual sensation. Medical professionals cannot investigate what they do not hear, and a patient’s body is sometimes the most sensitive sensor in the room.
For managers, the Therac-25 offers a blunt management lesson: safety is not a slogan for posters near the break room. It is a budget line, a schedule priority, a hiring decision, a documentation requirement, and a willingness to delay release when the evidence is not good enough. Teams usually do not drift into disaster because one person wakes up and decides to be careless. They drift through small compromises: ship now, test later, document someday, investigate after the next customer call. The machine does not care about the calendar. Physics does not accept Jira excuses.
For society, the experience is a warning about automation bias. People tend to believe computers because computers look precise. A numeric display feels objective. A software log feels official. A medical device feels authoritative. But authority without verification is dangerous. The healthiest relationship with technology is neither fear nor worship. It is disciplined skepticism.
The most haunting experience connected to the Therac-25 is imagining the patients who trusted a machine meant to help them. They came for cancer treatment, already carrying fear, pain, and hope. They deserved a system designed with layers of protection. They deserved warnings that made sense, investigations that moved fast, and a manufacturer willing to assume the worst until safety was proven. Remembering them keeps the Therac-25 from becoming just another classroom case study. It was not a puzzle. It was a human tragedy.
Conclusion: The Machine Did Not Act Alone
The title “Killed By A Machine: The Therac-25” is accurate, but incomplete. The machine delivered the radiation, but the deeper causes were human-made: overconfidence in software, weak safety analysis, poor interface design, missing independent interlocks, inadequate testing, slow incident recognition, and a culture that accepted “impossible” too easily.
The Therac-25 remains one of the most important warnings in the history of medical device software because it refuses to let us hide behind the word “bug.” Bugs are not mysterious gremlins. They are symptoms of decisions, assumptions, processes, and priorities. In safety-critical systems, the goal is not perfect software. The goal is a system that remains safe even when software is imperfect.
That is the final lesson: machines do not need malice to cause harm. They only need power, authority, and insufficient safeguards. The Therac-25 had all three. The next generation of medical devices, AI tools, robots, and automated systems must be built with the humility that this machine so brutally taught.
Note: This article is based on documented historical investigations, medical device safety literature, software engineering case studies, and radiotherapy risk-management discussions. It is written for educational and editorial publication purposes.
