alarm 1201 — deep dive

What the Apollo 11 Guidance Computer's most famous alarm actually means
Apollo 11 Lunar Module separation from the Command Module
NASA / Public Domain — Apollo 11 Lunar Module Eagle separating from the Command Module

The Alarm, Decoded

Alarm 1201 on the Apollo Guidance Computer (AGC) is formally known as Executive Overflow. It occurs when the program executive — the AGC's task scheduler — cannot service all its interrupt requests within the time window. The executive fills up. The system responds by dropping the lowest-priority queued tasks to free space for the highest-priority ones. The alarm is a warning, not a failure condition.

Key distinction: 1201 is an overflow warning. The AGC keeps running. It does not crash. It does not halt. It simply notifies the crew that it is shedding tasks. The landing program remains active unless the overflow becomes so severe that the executive cannot execute any program — which never happened on Apollo 11.

What Triggered It

During the powered descent phase of the Apollo 11 landing, the Lunar Module's rendezvous radar — which was supposed to be turned off — was sending data to the AGC because its mode switch was inadvertently left in the "on" position. The radar generated continuous interrupts. Combined with the heavy computational load of the descent guidance program (P65), the executive queue overflowed.

Why Ground Said "Keep Going"

At Mission Control in Houston, John Aaron — then a 29-year-old CAPCOM (Capsule Communicator) — recognized the alarms immediately. He had seen them in simulation months earlier and knew their character. He told his team: "Those alarms are fine. Keep going."

Decision-maker:
John Aaron (CAPCOM), backed by guidance program lead Don Eyles
Decision basis:
Simulation data confirmed 1201/1202 were non-critical overflow warnings
Crew response:
Armstrong and Aldrin continued descent based on ground confirmation
Result:
Successful landing at 20:17:39 UTC, Sea of Tranquility
Source:
The Apollo Flight Journal; John Aaron (engineer)

The AGC's Priority System

The AGC's executive scheduler ran programs at different priority levels. Landing guidance (P65/P60) ran at the highest real-time priority. Housekeeping, telemetry processing, and radar data processing ran at lower priorities. When overflow occurred, the system automatically dropped the lowest-priority pending tasks — preserving the landing program's execution time.

This is the same principle I use in my spreadsheets every single day: hard deadlines get the resources; everything else waits. The AGC didn't have machine learning or cloud compute. It had 4KB of memory and a rigid priority table. And it worked.

Technical Specs (Grounded)

AGC Manufacturer:
Raytheon
Programming Language:
Assembly language (AGC assembly)
Memory:
4 KB core rope (read-only) + 2 KB magnetic core RAM
Clock Rate:
~2 MHz (2048 kHz main oscillator)
Power Consumption:
~2 watts
Display System:
DSKY (Display and Keyboard)
Source Code:
github.com/chrislgarry/Apollo-11
Wikidata:
Q138875 (Apollo Guidance Computer)

What We Can't Do Better

We have AI agents that consume teraflops of compute. We have cloud platforms that scale elastically. And yet — when I look at how many systems fail because they try to do everything at once, I see that the AGC's discipline is still worth emulating. The computer didn't crash because it refused to compromise its core mission. It dropped work, reported the drop, and kept landing.

That's the lesson: Know your landing program. Drop everything else.