Your alert is not actionable just because it has a runbook link

The page needs a decision

Many alerts describe an interesting system state: CPU is high, a queue is deep, a pod restarted, or a certificate has thirty days left. Interesting is not the same as urgent. If an engineer cannot improve the outcome now, the event belongs in a dashboard, ticket, or automated workflow.

A page should arrive with a decision boundary. Traffic is failing and the responder can roll back. Capacity is exhausting and the responder can shed load. A dependency is degrading and the responder can fail over. Without that decision, the pager is just an expensive notification channel.

Runbooks rot where ownership is vague

A runbook that lists five possible causes and asks the responder to explore dashboards is not a runbook. It is a note that the system is poorly instrumented. Useful runbooks name the condition, confirm impact, show the next safe action, and state how to verify recovery.

They also have an owner and a test. If the recovery step cannot be rehearsed, the document is carrying hope instead of capability.

• What user behavior is failing?
• What changed recently?
• What action is safe now?
• How do we know the action worked?
• Who owns the alert after the incident?

Score every alert after it fires

During the reliability review, ask whether the page was urgent, correctly routed, and attached to an action that helped. If not, delete it, demote it, or redesign it. Do not keep noisy alerts because they might become useful during a future mystery.

A quiet pager is not a sign of weak monitoring. It is evidence that automation, thresholds, and ownership are doing their jobs before a human must intervene.

The goal is not to detect every abnormal state. The goal is to interrupt a human only when human judgment can still change the result.