Last month a scheduled passenger flight drifted off its cleared route for nearly thirty minutes before anyone noticed. Reports described the flight crew as having fallen asleep in the cruise phase. I am not a pilot. But I have spent enough late nights in a monitoring rotation to recognize the shape of the incident, because it is the same shape as half my tickets: the machine performed perfectly, and that perfection was the problem.
The autopilot did what autopilots do: it held a heading, kept the wings level, followed the programmed plan. For twenty-eight minutes it did this flawlessly. If you only watched the state — altitude stable, heading steady, engines cycling on schedule — nothing was wrong. The aircraft was doing exactly what it was told.
The failure lived one level up. Nobody was watching the second derivative: whether the current course still matched the cleared course. The plane wasn't malfunctioning. It was obediently going somewhere it had not been cleared to go — the way a misconfigured cron job, or a routing rule that points one subnet at a dead gateway, will keep a whole environment running smoothly, wrong, until someone happens to glance at the actual destination.
| Level | What it monitors | Why it failed here |
|---|---|---|
| State | "Is the plane flying?" | Yes. Altitude, heading, engines all nominal. Passed. |
| Course | "Is it where it was cleared to be?" | Not watched on this leg. This is the gap. |
| Intent | "Is the plan still worth following?" | Only the crew can judge this — and they were checked out of the loop. |
The lesson transfers straight to a server rack. Alerting on CPU use is monitoring state; alerting on "requests are being served but not reaching the database" is monitoring the course. State alerts keep you alive but blind. Course alerts tell you you're drifting off the map. Build your tripwires on course, and you shrink a twenty-eight-minute gap to a heartbeat.
Here is the discipline I keep returning to, the one I write in every onboarding note: decide, in advance, which silence is acceptable. Alert fatigue is not caused by too many alerts. It's caused by alerts that fire on state and never on course, so the ones that matter arrive drowned in the ones that don't. You don't fix that by silencing more; you fix it by retuning what counts as news.
“A human being can be lulled into unreadiness by a machine that is, by construction, uninterruptible. The bravest engineering is often deciding to make the quiet thing loud.” — field note, OPS-LOG 001
My rules of thumb, for myself and any team I land on:
The Apollo Guidance Computer — built by Raytheon, written in assembly language, its entire human interface a keypad-and-numbers unit called the DSKY — is my favorite counterexample. Its source is public: open the repo and you can read the exact instructions that flew to the Moon.
During the Apollo 11 descent, the computer began dropping low-priority tasks under a workload overload, and raised Alarm 1201. The crew did not have time to become experts. The flight team had already defined what that four-digit code meant, and the meaning was: the machine is dropping the safe tasks to keep descending — that is acceptable, continue. The plan lived before the panic. That is graceful degradation — the system deciding, in advance, which part of the mission to give up first.
That is the whole difference from the 28-minute gap. In the aircraft, the automation was too good at being uninteresting and nobody defined the second tripwire. In the Command Module, the automation was loud — four digits, unmistakable — and the tripwire had already been built the slow, unglamorous way: documented, rehearsed, written down before the emergency existed.