Most alerts get written as statements about a system: this queue is deeper than usual, this error rate crossed a line, this host is running hot. That framing is natural — it’s how the monitoring tool asks the question, and a threshold is the easiest thing to configure. But it isn’t what an alert actually does. An alert interrupts a person. Delivered at three in the morning, it asserts that whatever that person was doing, including sleeping, matters less right now than this condition. That’s a strong claim, and the threshold that produced it usually wasn’t chosen with that claim in mind.

The gap shows up as a specific kind of rot. An alert fires, someone looks, nothing is actually wrong, and they go back to what they were doing. It fires again next week and they look a little less carefully. After a few months, it’s an alert that everyone knows can be ignored, still wired up, still waking someone, providing negative value — it consumes attention and returns nothing. Worse, the habit generalizes: a team that has learned to dismiss one alert without reading it has learned a reflex that applies to all of them, including the one that matters. The failure isn’t that the alert was wrong on any particular night. It’s that it was never a claim anyone had reason to believe.

Deciding whether a condition deserves an alert gets much easier if you ask what the person receiving it is supposed to do. If the honest answer is “look at it, confirm it’s fine, go back to bed,” it isn’t an alert — it’s a dashboard entry, or a daily digest, or a ticket. If the answer is “there’s nothing to do until it gets worse,” it isn’t an alert yet; the alert belongs at the point where action becomes possible and necessary. An alert should be reserved for conditions where a human can do something now that matters, and where not doing it has a real cost. Everything else is information, and information has cheaper delivery mechanisms than interrupting someone’s night.

That reframing also changes what an alert should contain. If it’s a request for action, it ought to say what’s happening in terms of consequences rather than mechanics — customers can’t complete checkout, not p99_latency_ms > 3000 — because the mechanic is the evidence and the consequence is the reason anyone should care. It should say what’s expected of the person receiving it, or link to something that does. And it should be specific enough that they can tell, before they’re fully awake, whether this is the one they need to get up for. The threshold is the easy part; the surrounding context is what makes the interruption defensible.

The useful discipline, then, is to treat every alert as something that has to justify itself to a person, repeatedly, not just at the moment it was created. Alerts that stop earning their interruption should be demoted or deleted rather than tolerated, and the fact that one is noisy is data about the alert, not a personal failing of whoever keeps ignoring it. A page is the most expensive notification a system can send — it costs someone’s attention, their sleep, and eventually their willingness to take the next one seriously. Spending it well is the whole job.