With the lunar surface rushing closer, Buzz Aldrin read out a strange code from the guidance computer: 1202. Then it happened again. In the final minutes before the first Moon landing on July 20, 1969, Apollo 11’s onboard computer was overloaded badly enough to start throwing executive-overflow alarms during descent. If Mission Control judged them the wrong way, the landing would be aborted.
The Apollo Guidance Computer was tiny even by 1960s standards, and during Eagle’s descent it was suddenly being asked to do more than expected. NASA’s postflight analysis traced the alarms to the rendezvous radar being on in a configuration that kept feeding the computer extra work. In Houston, guidance officer Steve Bales needed an answer immediately. Behind him, 24-year-old Jack Garman recognized the alarm code and knew it was survivable if it did not become continuous.
Earlier simulations had already forced Mission Control and MIT’s software team to review how program alarms should be handled, and that review produced a GO/NO-GO cheat sheet for descent. The computer’s priority-driven executive also mattered: when overloaded, it dropped low-priority jobs, restarted, and kept the essential guidance tasks alive. That gave Bales a reason to tell Flight Director Gene Kranz to continue. Apollo 11 reached the surface because the system had been designed to fail gracefully and the decision path had been rehearsed before the crisis arrived.
The 1202 alarm showed how reliable systems survive overload. Apollo 11 got through the moment with a small computer that knew what to preserve and a team that had already decided what the alarm meant before it appeared. Complex systems do not survive on brilliance alone. They survive when overload is expected, triage is built in, and someone can say “go” without having to invent the logic in real time.
Craving more? Check out the source behind this Brain Snack!
