Slide 1
Apollo 11’s computer kept guiding through overload alarms
During Apollo 11’s 1969 Moon landing, the guidance computer issued overload alarms. Essential guidance could continue despite the extra work.
More to Read
The 1201 and 1202 alarms indicated exhausted executive resources. Mission control had to judge the alarms while descent continued.
Slide 2
Its limited memory had to serve vital tasks
The Apollo Guidance Computer coordinated navigation and control with memory measured in kilobytes. Its executive software organized jobs by priority.
More to Read
Its executive organized jobs by priority. Restart protection could resume essential work after an overload instead of treating every interrupted task as equally important.
Slide 3
Restarting protected work kept guidance running
The rendezvous-radar interface imposed an unexpected processing load. The software restarted protected work, including essential guidance.
More to Read
NASA's mission report traces the load to electrical timing at the radar–computer interface. Calling it simply too much useful radar data misses that distinction.
Slide 4
Mission control checked that guidance was continuing
With essential guidance still running, mission control advised the crew to proceed through the alarms. The decision depended on recognizing what the system was doing.
More to Read
The outcome depended on people interpreting system behaviour. An alarm is information for a decision, not proof that all failures can safely be ignored.
Slide 5
Resilience can mean protecting the most important work
Apollo’s example shows how resilience can mean preserving critical work when a system cannot do everything it was asked to do.
More to Read
Apollo's example joins software recovery with trained operators. Priority alone is not a guarantee: recovery has to retain the state needed for essential tasks.