Three minutes before Neil Armstrong and Buzz Aldrin touched the lunar surface on July 20, 1969, the yellow caution light on the Apollo Lunar Module’s display flashed a code: 1202. Then again. Then 1201. Five alarms in four minutes. The Apollo Guidance Computer, a compact box with limited memory, was telling its pilots it could not finish everything it had been asked to do.
Down in Houston, guidance officer Steve Bales had seconds to call abort or go. He called go. The reason he could call go, the reason Armstrong’s boot ever touched regolith, was that Margaret Hamilton, lead developer of the onboard flight software at the MIT Instrumentation Laboratory, had written the computer to triage itself.
The box that flew to the moon
The Apollo Guidance Computer was, by the standards of any device sitting on a desk today, almost laughably small. It had limited memory, each bit literally woven by hand through tiny ferrite cores. A modern microwave has more computing horsepower.
What it had instead of speed was discipline. Hamilton’s team at the MIT Instrumentation Lab, later renamed Draper, designed the software so the machine could decide, on its own and in real time, which jobs mattered and which jobs could wait. As Hamilton told CBS in a later interview, the descent computer was being overloaded by tasks from both the radar and the landing programs. The software had to detect the conflict, prioritise the available power, and keep flying.
What 1202 actually meant
The alarm code 1202, and its cousin 1201, was the AGC’s way of saying: I do not have enough time to finish all the work in this two-second cycle. The Executive program had run out of available areas to track active jobs. In a less-carefully written system, that condition would have meant a crash, a freeze, a hung machine above the Sea of Tranquility.
Hamilton’s code did something else. It threw away the lowest-priority work, restarted the machine in a controlled fashion, kept the highest-priority work. The jobs steering the descent engine, reading the inertial measurement unit, updating the displays for Armstrong. It carried on as if nothing had happened. Each 1202 was the computer surviving, not failing.
The rendezvous radar that should not have been on
The culprit was hardware, not software. The rendezvous radar, the radar that would later help the ascent stage find the orbiting Command Module, had been left in the wrong switch position during descent. Because of a mismatch between the radar’s reference signal and the AGC’s own timing, the radar’s counter was being incremented by spurious pulses, stealing a significant portion of the computer’s duty cycle for nothing useful at all.
Add that overhead to a descent program already running near capacity, and the Executive ran out of room. The computer should have been ignoring the radar entirely. Instead it was answering the door every few milliseconds for a guest who wasn’t there.
Priority scheduling, before the phrase existed
The principle Hamilton’s team had baked into the AGC is now standard in any operating system that has to meet a deadline: flight control, automotive braking, industrial robotics, financial trading. A real-time kernel assigns each task a priority. When the processor is saturated, the scheduler sheds the least urgent jobs and keeps the time-critical ones alive. That is the whole architecture of modern real-time Linux kernels, used today in defence systems, factory automation and high-frequency trading floors.
The same logic underpins research published in 2025 in Scientific Reports on scheduling for distributed heterogeneous parallel systems, describing the same fundamental challenge Hamilton faced. Allocating limited compute across competing tasks under hard timing constraints, using directed acyclic graphs and reinforcement learning to do what her team did with hand-traced flowcharts and rope memory.
Even the basic definition of processor scheduling, assigning a percentage of processor time to specific tasks based on importance, describes almost word for word what the AGC’s Executive did over the Moon.
The mother in the lab
Hamilton found a job at MIT working for meteorologist Edward Lorenz. From Lorenz’s weather-modelling group she moved to work on air-defence systems at MIT’s Lincoln Lab, writing code for systems that tracked Soviet bombers. Then she heard the Instrumentation Lab was hiring for Apollo. Hamilton later described being excited to join the Apollo program at MIT’s Instrumentation Lab, wanting to be part of the historic mission.
She was, in her own words, the only woman in the field at the start. She brought her young daughter Lauren into the lab on nights and weekends. It was Lauren, playing astronaut on a simulator, who accidentally launched a pre-launch program mid-flight and crashed the simulation, exactly the kind of human error Hamilton then wanted to defend against. NASA management told her not to worry. An astronaut would never do that.
During Apollo 8, Jim Lovell made a similar mistake, creating a navigation problem that Hamilton’s team worked to resolve from the ground. After that flight, as she remembered it, everyone joked that maybe she could put her preventive code in now.
Four minutes, five alarms
The Lunar Module Eagle began its powered descent high above the Moon. During the descent, the first 1202 lit up the DSKY display. Armstrong asked Houston for a reading on the alarm. Bales, looking at his console, conferred with MIT engineer Jack Garman, who had memorised the alarm codes on a hand-written cheat sheet. Garman’s call: as long as the alarm isn’t continuous, it’s a go.
The alarm was not continuous because Hamilton’s Executive was successfully restarting, killing the low-priority jobs, and re-establishing the critical ones every cycle. The descent guidance kept running. The display updates Armstrong needed kept appearing. The radar’s phantom pulses kept being deprioritised into oblivion.
Five alarms came up during the final minutes of descent. Armstrong, hand on the controller, flew Eagle past a boulder field he didn’t like and put it down with reportedly less than 25 seconds of usable descent propellant remaining. The priority scheduler shed lower-priority tasks instead of crashing.
The medal and the photograph
In 2016, President Barack Obama gave Hamilton the Presidential Medal of Freedom. At the ceremony, he recognized how her work had enabled the mission to continue despite the alarm conditions that arose during the lunar landing.
The photograph most people now associate with her shows her standing next to a stack of program listings, the Apollo flight software, printed out and bound. The stack is as tall as she is. Every line in those pages had been written, reviewed, simulated and woven into rope by hand.
What the 1202 left behind
The exact mechanism Hamilton’s team built (assign priorities, monitor load, shed gracefully) is now the unspoken assumption underneath every autopilot, every anti-lock brake, every pacemaker firmware update, every spacecraft that has to keep flying when something inside it goes wrong. Work on fuzzy clustering scheduling in cloud environments still wrestles with the same trade-off she made in 1968: which task gets the CPU, and which task waits.
The systems we depend on now, the chips that fly modern jets, the silicon coming out of fabs in Taiwan that power most of the world’s AI workloads, the schedulers that keep data centres from melting, all share an inheritance with the Executive program Hamilton’s team finished writing before Eagle ever left Earth.
Eagle’s footpads pressed into the lunar dust at 20:17:40 UTC on July 20, 1969, with roughly 25 seconds of descent propellant left in the tanks. Over the four minutes leading to touchdown, the AGC had raised five separate program alarms (four 1202s and one 1201) while the rendezvous radar’s spurious pulses were consuming an estimated 13 percent of the processor’s duty cycle. The computer ran on roughly 2,048 words of erasable core memory and 36,864 words of fixed rope, cycling at 2.048 MHz. Across all six crewed lunar landings between 1969 and 1972, the same Executive shipped without a single in-flight software failure attributable to its scheduler.
