Error 1202: The Alarm That Almost Stopped the Moon Landing

Twelve Minutes to History

July 20, 1969. The Lunar Module Eagle had just separated from the Command Module Columbia, and astronauts Neil Armstrong and Buzz Aldrin were beginning their powered descent to the surface of the Moon. Behind them, Michael Collins orbited alone in Columbia, waiting.

At Mission Control in Houston, hundreds of engineers and flight controllers monitored every parameter of the descent. In the back rooms, teams of specialists stood ready to advise the controllers on any anomaly. The atmosphere was electric with anticipation — and dread. No one had ever attempted a powered landing on another world.

At an altitude of approximately 40,000 feet, Armstrong and Aldrin initiated Program 63 (P63), the braking phase of the descent. The AGC — the Apollo Guidance Computer — took control, throttling the descent engine to begin slowing Eagle from its orbital velocity of roughly 5,500 feet per second.

Everything was nominal. The DSKY displayed velocity, altitude rate, and altitude. The numbers were moving in the right direction. Then, at an altitude of about 33,500 feet, with six minutes and thirty seconds remaining until touchdown, the DSKY lit up with an alarm no one wanted to see.

"Program Alarm"

The call came from Buzz Aldrin, his voice steady but urgent: "Program alarm." On the DSKY, the PROG indicator light was illuminated. Aldrin punched in V05 N09 E to display the alarm code. The registers showed: 1202.

Armstrong immediately radioed Houston: "It's a 1202."

In Mission Control, every eye turned to the guidance officer — a 26-year-old engineer named Steve Bales. Bales was responsible for monitoring the AGC and the Lunar Module's guidance systems. The 1202 code meant one thing: executive overflow. The AGC's task scheduler had more jobs queued than it could complete in the available time.

The computer was overloaded.

Bales had seconds to make a decision. If he called "No Go," the descent would be aborted. Armstrong would fire the ascent engine and return to orbit. The Moon landing — the entire purpose of Apollo 11 — would be scrubbed. If he called "Go" and the computer truly failed, two astronauts could die.

The Software That Saved the Mission

To understand why Bales called "Go," you have to understand the software running inside the AGC — software designed by Margaret Hamilton and her team at the MIT Instrumentation Laboratory.

Hamilton's team had built the AGC's operating system around a concept called the priority-based executive. Unlike a simple sequential program, the executive could manage multiple tasks running concurrently, each assigned a priority level. When the computer became overloaded, it did not crash. Instead, it did something remarkable: it shed the lowest-priority tasks and continued executing the highest-priority ones.

This was not an accident. Hamilton had insisted on building robust error recovery into the software. She had argued — against skepticism from some NASA managers — that software could and would encounter unexpected conditions during a mission. Her team designed the system so that the AGC would always prioritize the tasks essential to keeping the astronauts alive: guidance, navigation, and control.

The 1202 alarm was the executive's way of reporting that it had been forced to restart lower-priority tasks because there was not enough processing time to complete them all. But — and this was the critical detail — the essential guidance computations were still running correctly.

What Caused the Overload

The root cause of the 1202 alarm was traced to the rendezvous radar. Before the descent, a checklist item had called for the rendezvous radar to be set to a specific position. The radar was intended for use during the ascent from the lunar surface, when Eagle would need to find and dock with Columbia. During descent, it was not needed.

However, the radar was left powered on and in a mode where it was sending data to the AGC. The radar's counter registers were being updated asynchronously — driven by an AC power source running at a frequency slightly different from the AGC's clock. This created a steady stream of "counter increment" interrupts that the AGC had to process.

Under normal circumstances, the AGC could handle these interrupts. But during the powered descent, the computer was already running at near-maximum capacity, processing the guidance equations for P63, monitoring the inertial measurement unit (IMU), controlling the descent engine throttle, managing the DSKY display updates, and handling telemetry to Mission Control.

The additional load from the rendezvous radar pushed the AGC past its capacity threshold. The executive detected the overflow and triggered the 1202 alarm.

In the back room at Mission Control, Jack Garman — a 24-year-old computer engineer — had prepared for exactly this scenario. Weeks before the mission, during a simulation, a similar alarm had appeared. Garman had researched the alarm codes and compiled a reference list. He had taped a handwritten note to his console: 1202 alarm — if it does not recur, Go.

When Bales turned to his back room and asked, Garman's response was immediate: "It's a Go."

"We're Go on That Alarm"

Bales keyed his microphone: "We're Go on that alarm." Flight Director Gene Kranz relayed the call to the crew via CapCom Charlie Duke: "Roger, we got you. We're Go on that alarm."

The descent continued. But the reprieve was short-lived. At about 2,000 feet altitude, another alarm appeared: 1201. This was closely related to the 1202 — a "no vacant areas" alarm, meaning the AGC's job queue was completely full. Again, the priority executive shed non-essential tasks and kept the guidance running.

Bales confirmed once more: "Same type. We're Go."

The alarms would flash intermittently for the remainder of the descent, each time causing a momentary surge of adrenaline in Mission Control. Each time, the software performed exactly as Hamilton's team had designed it. The essential computations continued uninterrupted.

The Final Descent

While the computer alarms dominated the radio chatter, Armstrong faced another crisis. Looking through the LM window, he could see that the computer's targeted landing site was in a boulder field at the edge of a large crater — what would later be named West Crater. The terrain was far too rough for a safe landing.

Armstrong took semi-manual control using Program 66 (P66), which allowed him to override the computer's automatic guidance while the AGC continued to manage the throttle and attitude. Using the hand controller, he flew Eagle past the boulder field, searching for a smooth landing spot.

The DSKY displayed the dwindling propellant supply. CapCom Charlie Duke called out the remaining time:

"Sixty seconds." This meant sixty seconds of fuel remaining before a mandatory abort.

Armstrong found a clear area and began his final approach. The LM's shadow appeared on the surface below. Dust kicked up by the descent engine began to obscure the ground.

"Thirty seconds."

Then, a new voice came from the DSKY display — not an alarm this time, but a contact indication. The 67-inch probes dangling below Eagle's footpads touched the lunar surface.

Aldrin called it: "Contact light."

Armstrong shut down the engine. Eagle settled onto the Moon with a gentle thump.

"Houston, Tranquility Base here. The Eagle has landed."

Charlie Duke, his voice breaking with emotion, replied: "Roger, Tranquility. We copy you on the ground. You got a bunch of guys about to turn blue. We're breathing again. Thanks a lot."

The Technical Aftermath

After the mission, NASA conducted an exhaustive investigation into the 1202 and 1201 alarms. The root cause was confirmed: the rendezvous radar's asynchronous counter updates had consumed approximately 15% of the AGC's processing capacity during a phase where the computer was already operating at 85% load.

The fix was straightforward. For subsequent Apollo missions, procedures were changed so that the rendezvous radar was placed in a different mode during powered descent, eliminating the spurious interrupts. The alarms never recurred on later flights.

But the real lesson was not about radar switches. It was about software design.

Margaret Hamilton's Legacy

Margaret Hamilton's insistence on building a priority-based, fault-tolerant executive into the AGC software was vindicated on the most important day in the history of spaceflight. Without the executive's ability to shed non-critical tasks and continue essential guidance computations, the 1202 alarm would have meant an abort — or worse, a crash.

Hamilton later recalled that some NASA managers had questioned the need for such elaborate error-handling software. "They said, 'That will never happen,'" she remembered. "I said, 'But what if it does?'"

It did. And because she had prepared for it, Armstrong and Aldrin walked on the Moon.

The Apollo 11 1202 alarm became a landmark case study in software engineering — a field that Hamilton herself helped name. It demonstrated that software robustness was not a luxury but a necessity for any safety-critical system. The principles she pioneered — asynchronous error recovery, priority scheduling, graceful degradation — are now fundamental to every operating system, every real-time control system, and every safety-critical application in the world.

The Human Element

The 1202 alarm story is often told as a triumph of engineering, and it is. But it is also a story of human courage. Steve Bales was 26 years old. Jack Garman was 24. They had seconds to make a call that would determine whether humanity landed on the Moon. They had prepared meticulously, trusted their analysis, and made the right call under unimaginable pressure.

Gene Kranz, the flight director, later said of the moment: "When I heard Steve's voice say 'Go,' I knew we had the right people in the right places."

Neil Armstrong, in his characteristically understated way, described the alarms as "a rather unpleasant surprise." He later acknowledged that without the software's ability to keep running through the overload, "we would not have made it."

What 1202 Means Today

The 1202 alarm has become an icon of resilience in engineering culture. Software developers cite it as a textbook example of graceful degradation. It appears on T-shirts, coffee mugs, and — at apolloreplica.com — on the displays of faithfully reproduced DSKY replicas.

But beyond the cultural symbolism, the 1202 carries a deeper lesson: the importance of designing systems that fail gracefully rather than catastrophically. Margaret Hamilton and her team could not predict every scenario the AGC would encounter. Instead, they designed software that could handle the unexpected — software that kept working when the plan fell apart.

In an age of increasingly complex and autonomous systems, from self-driving cars to AI-powered spacecraft, that lesson has never been more relevant. The 1202 alarm reminds us that the measure of great engineering is not whether things go wrong — they always will — but what the system does when they do.