Apollo 11’s 1201 and 1202 Alarms: The Near-Failure That Proved Priority Scheduling
The Apollo 11 program alarms were caused by computer overload during descent, but the priority-driven executive and restart design preserved the critical guidance tasks and allowed the landing to continue.
The most famous Apollo software alarm happened minutes before landing
During Eagle’s powered descent on July 20, 1969, the Apollo Guidance Computer suddenly displayed program alarm 1202, followed by additional 1202 and 1201 alarms.[1] Neil Armstrong and Buzz Aldrin did not have time to diagnose an operating-system resource problem while descending toward the Moon. Mission Control had to decide whether the alarms meant the landing should be aborted. After a rapid interpretation by guidance specialists, Charlie Duke relayed the call to continue.
The alarm was a capacity warning, not a crashed computer
The computer was overloaded, but it was still executing the highest-priority work needed to fly the lunar module.
The Apollo computer used a priority-driven real-time executive
The AGC’s Executive scheduled jobs by priority rather than giving every task an equal turn. NASA’s technical histories describe a system in which higher-priority jobs could displace lower-priority work, while restart tables and phase information preserved essential computation after an overload or fault.[2] The architecture reflected the reality of flight control: updating guidance and engine commands matters more than refreshing a display or completing a noncritical background calculation.
Rendezvous-radar activity consumed enough resources to overflow the job system
Accounts from MIT programmers explain that an electrical configuration involving the rendezvous radar caused a stream of counter increments and related processing during the descent.[3] That extra work consumed a meaningful fraction of the computer’s limited capacity. Jobs began arriving faster than some lower-priority work could complete, eventually exhausting the Executive’s available core sets and temporary work areas. Alarm 1202 indicated no core set was available; 1201 was associated with exhaustion of a VAC work area.
The radar did not need to be “broken” for the overload to occur
The failure was an interaction among hardware mode, timing, interrupt load, and finite software resources.
The restart mechanism discarded low-value work and reconstructed critical state
When the Executive detected overload, it did not simply freeze or reboot from a blank state. The restart logic reinitialized the computer while preserving enough phase information to restart essential flight programs near the correct point in their execution.[2] Guidance and control survived while less important work was abandoned. NASA later described this restart capability as one of the defining reliability features of the Apollo computer.[4]
Jack Garman and Mission Control had to trust the design under pressure
The software’s recovery behavior mattered only because people understood what the alarms meant. Flight controller Jack Garman had studied the alarm codes and advised that the landing could proceed when the computer continued producing valid guidance.[1] The decision was not blind faith. It rested on knowledge of the Executive’s priorities and restart behavior, plus the observation that critical navigation outputs remained sensible.
Operational knowledge was part of the safety system
A technically resilient computer still needed humans capable of distinguishing a recoverable overload from a condition that required aborting the mission.
The incident did not “invent” priority scheduling during the landing
The roadmap title calls the event a near-failure that proved priority scheduling, and that is the right historical framing. The scheduling and restart system had been designed and tested long before Apollo 11.[5] The landing demonstrated its value under an unexpected load. The software did not improvise a solution in flight; it executed a resilience strategy engineers had already embedded into the operating system.
The alarms changed how later engineers understood real-time overload
Fred Martin later argued that Apollo 11 showed why a priority-driven executive was superior to designs that tried to guarantee equal service to every task.[3] In a hard real-time system, overload is not hypothetical. The important question is which work survives when the machine cannot do everything. Apollo’s answer was to make priorities explicit and to design restart behavior around mission phases.
Graceful degradation can be safer than pretending overload will never happen
A system that knows what to sacrifice can remain functional under conditions that would crash a design built only for nominal capacity.
Why the 1201 and 1202 alarms belong in software-failure history
The Apollo 11 alarms are unusual because the visible failure demonstrated the success of the underlying software architecture. The overload was real, and continuing the descent carried risk, but the Executive’s priority scheduling and restart mechanisms protected the flight-critical work.[2][4]
The episode remains a model for safety-critical computing. Engineers cannot guarantee that every timing assumption will hold forever. They can, however, define priorities, detect overload, preserve critical state, and make degraded modes understandable to operators. Apollo 11 landed not because the computer never failed, but because the software knew how to fail without surrendering the mission.
The incident also highlights the distinction between scheduling and overload recovery. Priority scheduling ensured that guidance work outranked less important tasks, but the restart mechanism was what converted resource exhaustion into a recoverable event. A system can have correct priorities and still fail if exhausted queues, memory pools, or timing budgets leave it no way to shed work. Apollo combined priority assignment with bounded job resources and restart points that were designed around mission phases. Modern real-time systems make the same distinction through admission control, watchdog recovery, load shedding, and criticality levels.
Works Cited
- 01NASA Apollo 11 Lunar Surface Journal — Program Alarms history.nasa.gov
- 02NASA — Computers in Spaceflight: The NASA Experience ntrs.nasa.gov
- 03
- 04NASA — Apollo Guidance Computer Restart Features ntrs.nasa.gov
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.