The radiation machine whose software quietly killed its patients
It was supposed to be one of the safest, most modern ways to treat cancer: a computer-controlled machine that aimed precise beams of radiation at a tumour. Instead, on a handful of days in the 1980s, it fired enormous overdoses into people who had come to be healed, and for a long time the doctors could not work out why. The Therac-25 became the most infamous example of software that kills.
A machine built to deliver careful doses, undone by a flaw no one could see. Illustration: Watts & Wild.
Radiation therapy is a balancing act. Enough energy to kill cancer cells, not so much that it destroys healthy tissue, all delivered by a machine the staff have to trust completely. The Therac-25 broke that trust in the worst way, by appearing to work perfectly while occasionally giving patients a dose that no human body could survive.
Its story is now taught to engineers everywhere, because it is not really about one faulty machine. It is about what happens when we let software be the only thing standing between people and harm.
A machine meant to heal
The Therac-25 was a radiation therapy machine built by Atomic Energy of Canada Limited and installed in hospitals across North America in the mid-1980s. It could switch between a gentle electron beam for shallow tumours and a powerful X-ray mode for deeper ones, all chosen by an operator typing at a computer terminal.
To make the X-ray mode safe, a metal target had to swing into the path of the high-power beam to soften and shape it. In electron mode, that target moved out of the way and the beam ran at a far lower power. Everything depended on the machine always matching the beam to the right hardware position. When it did, treatment was routine. When it did not, the result was catastrophic.
How the Therac-25 software bug killed patients
The flaw lay in the timing of the software. If an experienced operator typed in the settings and then quickly corrected them, switching modes within about eight seconds, the program could become confused and skip a crucial safety check.
In that narrow window, the machine could fire its high-power electron beam with the X-ray target still out of the way and nothing to spread the energy out. The patient received a concentrated blast, by some estimates around a hundred times the intended dose, focused on a small patch of their body. Programmers call this kind of timing trap a race condition, and it is exactly the sort of error that almost never shows up in testing, because it only happens when events line up in one unlucky order.
The shock that no one believed
Patients knew at once that something was wrong. They described a stab of heat or an electric shock the instant the beam fired, far from the mild, painless treatment they had been promised. Yet the machine usually just displayed a brief, meaningless error like "Malfunction 54", so operators often assumed nothing serious had happened and simply tried again.
For months the overdoses were dismissed or doubted. The manufacturer at first insisted the machine could not deliver too much radiation, and could not reproduce the fault. It took the stubborn work of a hospital physicist in Tyler, Texas, who painstakingly recreated the exact sequence of keystrokes, to prove that the Therac-25 really was burning patients, and that the cause was buried in its code. By then several people had been gravely harmed, and some had died.
Why software alone was not enough
The deeper failure was not a single typo in the code. Earlier versions of the machine had used physical safety locks that physically stopped the beam in unsafe positions, but the Therac-25 dropped them and trusted the software to get everything right on its own.
On top of that, old code was reused without being properly retested, the error messages told operators almost nothing, and warnings were brushed aside for too long. When the investigators Nancy Leveson and Clark Turner pieced the whole story together, it became the founding case study of software safety, a permanent reminder that life-critical systems need more than one layer of protection. Today, as software quietly takes the controls of cars, planes, and medical machines, the Therac-25 is the cautionary tale engineers cannot afford to forget.
What went wrong with the Therac-25?
A hidden timing flaw met a missing safety net. A race condition in the software let the Therac-25 fire its full-power beam without the protective target in place, and because the machine had no hardware locks to catch the mistake, nothing stopped the overdose from reaching the patient.
It is worth being clear that no single person set out to cause harm. The tragedy grew out of many smaller failures stacked together: confident assumptions, reused code, vague error messages, and a slow response to the first warnings. That is what makes it so unsettling. The Therac-25 did not fail because someone was reckless on one day, but because a whole chain of reasonable-seeming decisions left patients with no protection when the software finally slipped.
How many people did the Therac-25 kill?
At least three, out of six known serious overdoses. Between 1985 and 1987 the Therac-25 gravely overdosed at least six patients, and at least three of them died of their injuries, with others left badly burned.
Behind those numbers were real people who walked into a clinic expecting help and were harmed by a machine no one yet understood. Their cases forced hospitals, regulators, and engineers to take software safety seriously in a way they never had before. It is a hard kind of legacy, but the rules and habits that now protect patients from the next Therac-25 exist because of what happened to them.
A machine built to save lives took them instead, because we trusted code to do a job it was never made safe enough for. How much of your own life now rests on software that no one has truly proven cannot fail? Tell us what you think in the comments.
Related reading: the Morris worm, the student program that accidentally froze a tenth of the early internet.
