Five computer-overload alarms interrupted Apollo 11’s powered descent on 20 July 1969. Four carried the code 1202 and one carried 1201. Each meant that Eagle’s guidance computer had been asked to schedule more work than its small supply of temporary working areas could support.
The computer responded by entering a software restart, clearing unfinished and dispensable jobs, then resuming the programmes marked as essential. Navigation, guidance and engine-control calculations survived. Some crew-requested displays did not.
Calling that sequence a reboot is reasonable shorthand, and programmers who worked on Apollo have used the word themselves. It was not a modern cold reboot. The machine did not power off, reload everything from the beginning and forget where the Lunar Module was in its descent.
Five alarms appeared during two descent phases
An MIT Instrumentation Laboratory analysis dated 4 August 1969 records the five alarms relative to powered descent initiation. The first 1202 came 316 seconds after ignition, followed by another at 356 seconds. A 1201 appeared at 552 seconds, then two more 1202 alarms at 578 and 594 seconds.
The first pair occurred while the Lunar Guidance Computer was running P63, the braking phase. The final three came in P64, the approach phase, in a burst lasting about 42 seconds.
NASA’s Apollo 11 mission report places the first computer-determined alarm at a mission elapsed time of 102 hours, 38 minutes and 22 seconds. The crew read the code aloud moments later. “Give us a reading on the 1202 program alarm,” Neil Armstrong asked Houston.
Mission Control answered through capsule communicator Charlie Duke: “We’re Go on that alarm.”
The call did not mean the alarm was harmless. Guidance officer Steve Bales, supported by Jack Garman and other specialists, could see that the guidance data remained coherent and the computer was recovering between occurrences. The landing could continue while essential outputs remained valid and the overload did not become continuous.
What 1201 and 1202 actually reported
The Apollo Guidance Computer had one processor, so its jobs did not literally run simultaneously. Executive software maintained queues, assigned priorities and allowed a higher-priority job to suspend a lower-priority one.
Every scheduled job needed a small private block of erasable memory called a core set. A job requiring more temporary workspace also requested a larger Vector Accumulator area, shortened to VAC.
The Lunar Module computer had seven core sets and five VAC areas. Alarm 1202 meant the Executive had received another request when no core set was available. Alarm 1201 meant no VAC area remained.
That is more precise than saying the computer simply ran out of memory or crashed. Its fixed programme memory was intact, and the processor was still executing instructions. The scheduler had exhausted the temporary resources needed to begin another job because earlier instances had not finished before new copies were requested.
The rendezvous radar consumed the missing cycles
The overload was not caused by a useful torrent of rendezvous-radar measurements entering the computer. The mechanism was an electrical interface problem.
The radar’s shaft and trunnion angles were represented by electromechanical devices whose digital interfaces could ask the guidance computer to increment counters. When the radar switch was in AUTO TRACK or SLEW instead of the computer-controlled LGC position, two 800-cycle-per-second reference signals could have an uncontrolled phase relationship.
The angle-conversion electronics responded by generating spurious counter-increment requests, potentially at 6,400 pulses per second on each of two channels. Every request consumed one memory cycle even though the resulting work was not useful to the landing programme.
The MIT post-flight analysis calculated that this “cycle stealing” took about 15 per cent of the computer’s execution time. The landing software had been tested with a margin intended to tolerate about 10 per cent lost time while a monitor display was running. Apollo 11 crossed that margin.
Guidance jobs operated on fixed schedules. With the processor slowed, an earlier copy could still be running when the clock requested the next one. Duplicate instances accumulated until the Executive had no free core set or VAC area.
The crew checklist instructed Armstrong and Buzz Aldrin to place the rendezvous radar in AUTO TRACK before calling P63. This was not a simple case of an astronaut moving the wrong switch. The approved procedure, electrical interface and software-verification simulator failed to reproduce the same combined condition before flight.
BAILOUT restarted only the required work
When the Executive could not allocate a core set or VAC area, it illuminated the programme alarm, stored the 1201 or 1202 code and transferred control to a routine named BAILOUT.
BAILOUT stopped active jobs and tasks, then used restart information prepared by the programmers to restore required work. Navigation, guidance, engine steering and the crew interface returned. Temporary monitor displays and other astronaut-requested activities were not necessarily restarted automatically.
This removed the duplicate and unfinished work that had occupied the scheduling areas. The noisy radar interface continued stealing cycles, so overload could recur, but every restart reduced the accumulated queue and gave the essential jobs room to run again.
Peter Adler, one of the MIT programmers who worked on Lunar Module powered-flight software, later described the sequence in an account preserved by NASA’s Apollo Lunar Surface Journal. His modern-computer analogy imagined returning to an active document after a reboot while leaving lower-priority background programmes closed.
The analogy captures the visible result. “Software restart” remains the more precise description because protected mission state survived and selected programmes resumed at prepared restart points. The computer did not reconstruct the descent from zero.
Armstrong’s manual landing still depended on the computer
The alarms did not lead Armstrong to abandon the guidance computer. Late in the approach he selected P66, the rate-of-descent landing mode, to fly beyond a boulder-strewn area. Armstrong commanded the descent rate and attitude changes through the hand controls, while the computer continued processing navigation, stabilisation and engine commands.
Manual control did not mean computer-free control.
P66 gave the commander more direct authority over the landing path inside a computer-mediated control loop. The priority scheduler and restart system remained part of that loop until touchdown at 102 hours, 45 minutes and 40 seconds mission elapsed time.
The recovery logic also had a limit. It could clear a temporary backlog, but it could not make a permanent overload safe. Had the spurious workload prevented required guidance jobs from completing after a restart, Mission Control would have needed to call an abort.
The next software version stopped the useless requests
The post-flight investigation traced the cause quickly because Apollo 11 still had to leave the Moon. Before ascent, Mission Control asked the crew to place the rendezvous radar switch in manual rather than repeat the descent configuration.
For the later Luminary 1B flight software, engineers added logic to check whether the radar was actually in LGC mode. When it was not, the computer commanded the angle-conversion electronics to zero, preventing the meaningless counter increments from consuming processor time.
MIT also reviewed simulator fidelity, checklist review and communication between hardware and software teams. The Executive had handled the overload as designed, but the mission had exposed a hardware-software interaction that the end-to-end tests had missed.
The computer did not survive because it possessed unused processing power. It survived because overload was treated as a condition to manage: announce the shortage, preserve state, remove work that could be sacrificed and resume only what the landing still required.
