Skip to content
MartinMediaLLC.com
MARTIN MEDIA

Conservative & Faith-Forward · Est. 2026

Science & Technology

The 1202 Alarm

By Kevin Marsibilio · July 15, 2026 · 9 min read

Part of Dare Mighty Things·Apollo

1202

The alarm code nobody had seen in training, the engineer who knew what it meant, and the four seconds that decided the Apollo 11 landing

Part of the Dare Mighty Things series — Apollo | Estimated read time: 6 minutes

Jack Garman was 24 years old, and the fate of the Apollo 11 landing was now his to decide.

It was July 20, 1969. Seven minutes and thirty seconds before the Eagle was scheduled to touch down on the Moon, an alarm had flared on the display panel inside the lunar module. Armstrong's voice came over the radio — calm, but with what the transcript would later describe as "the slightest touch of urgency." He read out the number.

1202.

In the Mission Control support room where Garman sat, guidance officer Steve Bales was already calling him. "Jack, what the hell is going on with those program alarms?" The telemetry delay between the Moon and Earth meant that Bales and Garman saw the alarm about three to four seconds after it appeared before Armstrong and Aldrin. They had perhaps that long to respond before the crew — hearing silence — might take matters into their own hands.

Garman looked down at the sheet of paper under the plexiglass on his desk. He had written it himself, by hand, weeks earlier. Every computer alarm code that could possibly occur during a lunar landing. What each one meant. What to do.

He found 1202.

He looked up. He called it.

"We're go on that alarm."

The Machine That Got Them There

To understand what the 1202 meant, you first have to understand the computer that threw it — because the Apollo Guidance Computer is one of the most remarkable machines ever built, and almost nobody knows it exists.

In 1969, most computers filled entire rooms. The AGC had to fit inside a spacecraft. It occupied roughly a cubic foot of space. It weighed 70 pounds. It operated on 4 kilobytes of erasable memory — roughly one-ten-thousandth of what a modern smartwatch carries. Its fixed memory, which held the actual flight programs, was hand-woven: skilled technicians at Raytheon spent weeks threading thin copper wire through tiny ferrite rings, each thread representing a binary digit, each loop painstakingly placed by human hands. A single memory module cost about $15,000 in 1969 dollars. The AGC used 36 of them.

The software running on this machine was written at MIT's Instrumentation Laboratory — a group of engineers who had to invent not just the programs but the entire discipline of writing software for a machine that would navigate humans through the vacuum of space with no possibility of a patch, an update, or a reboot by a support technician. They wrote the code. They tested it obsessively. They built in safeguards.

One of those safeguards was priority scheduling.

The AGC's operating system was designed around a simple principle: not all tasks are equally important. If the computer became overloaded — if it had more work queued than it could complete in a given processing cycle — it would shed the lowest-priority tasks and protect the highest ones. Navigation. Guidance. Engine control. The things that kept the spacecraft flying properly were always done. The things that could wait — display updates, certain radar calculations — would be dropped.

When the computer dropped tasks this way, it would restart, clear its queue, and flag the event with an alarm code. The 1202 was one of those codes. It meant: "I have run out of memory space for scheduled jobs. I am shedding lower-priority tasks. My critical functions are intact and running."

This was, in the language of software engineering, a feature rather than a bug. The computer was doing exactly what it had been designed to do under overload conditions. The question — the one that had to be answered in four seconds — was whether the overload would remain manageable or would cascade into something the computer couldn't recover from.

Why It Was Happening

The cause of the overload was an embarrassingly small thing.

The Eagle's rendezvous radar — the system designed to track the orbiting Columbia in case Armstrong and Aldrin needed to abort and return to orbit — had been left running in AUTO mode during the descent. This was standard procedure; it meant the radar would be ready immediately if an abort became necessary. What nobody had fully appreciated was that in AUTO mode, the radar was generating rapid, spurious signals that the computer was trying to process — a steady stream of data the computer didn't actually need, flooding its scheduler like someone repeatedly hitting a request button on a website that's already under load.

Normally, the AGC ran at about 83 percent of capacity during powered descent. The radar was adding the equivalent of another 13 percent. That left the computer at the edge of what it could handle. When Aldrin entered a command asking the computer to calculate and display altitude data, it pushed the system over the edge by just enough.

The computer ran out of processing time, threw the 1202, shed its lower-priority tasks, restarted, and kept flying the spacecraft.

This had actually been documented as a potential issue before the mission. A design review had identified the problem with the radar's signal generation — but it had only occurred once during testing and had been deemed unlikely enough to ignore. The engineers concluded it was safer to fly with tested hardware than to modify it at the last minute.

That decision would have aborted the landing if not for the list under the plexiglass on Jack Garman's desk.

The List

Several weeks before Apollo 11 launched, a simulation exercise had almost derailed everything.

During a practice landing run, the 1202 alarm had appeared. Steve Bales, the guidance officer responsible for calling go or no-go on the alarm during the mission, had done the safe thing and called an abort. The simulation controllers declared it a bad call — the alarm was manageable, and the abort was unnecessary.

Gene Kranz, reviewing the exercise afterward, sat Garman down and told him what he wanted. He didn't want Garman to know the most common alarms, or the most likely alarms, or just the important alarms. He wanted Garman to write down every possible alarm code — including the ones that shouldn't happen and those that had never been seen in simulation — and note beside each one exactly what the correct response was.

Garman spent a week on it. He consulted the MIT engineers. He cross-referenced the flight rules. He went through the software documentation, alarm by alarm, code by code, and wrote his answers on a single sheet of paper in his own handwriting. Bales had a copy taped to his console. Garman kept his under the plexiglass.

Neither of them expected ever to use it.

Five Alarms

The first 1202 fired at seven minutes and thirty seconds before landing.

Garman called go. Duke relayed it to Armstrong. The descent continued.

Fifty-four seconds later: another 1202.

Garman called go again. In the Mission Control support room, he was, by his own later account, yelling. Not in panic — in volume, because the communication loops were loud and the call had to be clear. "GO!" The 1202 was the same type as before. The computer was shedding tasks and recovering. Nothing critical was affected.

Two minutes and twenty-four seconds later: a 1201 — a variant of the same executive overflow family, indicating that the computer had run out of a different type of register space. Same cause. Same behavior. Same answer.

Garman called go.

Two more 1202s followed in quick succession, the last of them firing less than three minutes before landing when the Eagle was less than 500 meters above the surface — already deep into the final approach, already committed to a landing attempt if the systems held.

Each time, Garman checked the list. Each time the answer was the same. Each time the call went up: go.

The computer kept shedding tasks. The computer kept recovering. The guidance, navigation, and engine control kept running without interruption. The Eagle kept descending.

Armstrong, watching the surface approach through his window, saw the boulder field below and took manual control. He still had five computer alarms ringing in his recent memory and was now flying the spacecraft by hand over unfamiliar terrain with dwindling fuel. He found a flat patch beyond the crater and put the Eagle down with somewhere between seventeen and thirty seconds of fuel remaining.

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

What Would Have Happened

If Garman had called abort on the first 1202, the mission would have ended there.

An abort from that altitude, at that phase of powered descent, was survivable. Armstrong and Aldrin would have fired the ascent engine, risen back to orbit, rendezvoused with Collins in Columbia, and come home. They would have been alive. The mission would have been designated a partial success — the hardware worked, the crew survived, and the landing would happen on Apollo 12.

But Armstrong and Aldrin had not practiced any of this in simulation. They had not been briefed on program alarms or their causes. When the 1202 appeared, they didn't know if it was manageable or terminal — they were entirely dependent on the people in Mission Control to make that call, and the people in Mission Control were entirely dependent on the one engineer in the support room who had spent a week that nobody asked him to spend writing down every alarm code he could find.

"You don't realize until years later," Garman said afterward, "how doing the wrong thing at the right time could have changed history. If Steve had called an abort, they might well have aborted."

He was right. He also knew the answer. Those two things together — the knowledge and the moment — are what made the landing possible.

Garman went on to spend thirty years at NASA, eventually serving as Chief Information Officer at Johnson Space Center. He retired in 2000. He died in September 2016, fifty years after he graduated from the University of Michigan and began working for NASA at the age of 21.

He was buried without most people knowing his name.

The list is still out there. A sheet of paper, handwritten by a 24-year-old engineer, contained the correct answer to every alarm that could have stopped humanity from reaching the Moon.

This article is part of the Dare Mighty Things series — Apollo branch.

  • [← Back to Apollo: The Audacity — the full Apollo hub]

  • [← Back to the main series: Dare Mighty Things — The Story of America's Space Program]