The two pieces before this one argued that an alert is a claim that a specific person should act, and that most alert coverage is a map of past incidents rather than of the ways a system can actually break. Both point at the same missing half. Alerts get designed as a detection problem — what condition, what threshold, what query — and the part where a human, mid-sentence or mid-sleep, has to figure out what to actually do is left to improvisation. Detection that produces no useful action isn’t monitoring. It’s a notification budget being spent on making someone anxious.

You can see the gap most clearly in what a good page contains versus what a typical one does. A typical one says a metric crossed a line. A useful one tells you what’s broken in terms someone cares about, how bad it is right now, what the most likely causes are given what else is happening, and what the first thing to check is. The last part is what turns an alert from an announcement into a starting point. It doesn’t have to be a full runbook — often a single link, one prior incident, or one sentence naming the usual culprit is the whole difference between a responder oriented in thirty seconds and one reading dashboards for twenty minutes to rebuild context that someone already had months ago.

This also gives you a sharper test than “is this alert noisy.” Ask instead: when this fires, does the person receiving it know what to do, and can they do it? If the answer is no because there’s no documented response, the alert is incomplete and the fix is to write the response down. If it’s no because the responder lacks access or authority to act, the alert is pointed at the wrong person, and routing it correctly matters more than tuning its threshold. And if the honest answer is that there’s nothing to be done at all — the condition is real, it’s visible, and no available action changes it — then it shouldn’t be waking anyone up, no matter how true it is. True and actionable are different properties, and only one of them justifies an interruption.

Treating the response as part of the alert also changes when this work happens. The natural moment to write down what to do is when you already know — right after an incident, while the reasoning is still fresh — not months later when someone new gets paged and has to rediscover it from scratch. That’s the same asymmetry that shows up everywhere in operational work: capturing context is cheap while you have it and expensive once it’s gone. An alert created without its response is a deferred cost, and the person who pays it is whoever happens to be on call the night it fires.

Which brings the thread to its point. An alerting system isn’t a set of thresholds; it’s a set of claims about what matters, paired with what should happen when those claims come true. Thresholds are the easy half, which is why most of the effort goes there. The half that determines whether any of it works is what the person on the other end can actually do with the interruption — and that half is a design decision, made in advance, or it isn’t made at all.