Page and Ticket Routing
Deciding for each monitored condition whether it warrants immediate human interruption or asynchronous handling, and enforcing the distinction.
Every alert rule should answer one question: does a human need to act within minutes? If not, it is not a page.
Page when users are being affected now, the situation will worsen without intervention, and there is something a responder can do. Elevated error rate against the SLO, a fast error-budget burn, a critical dependency failing, a security event.
Ticket when the condition is real but bounded in time. Disk filling in six days, certificate expiring in three weeks, a slow error-budget burn, an unhealthy instance already replaced by autoscaling, a batch job that failed and will be retried.
Neither when nothing will be done. Then it belongs on a dashboard, or nowhere.
The failure this prevents: teams routing everything to a page because "it might be important". The result is alert fatigue, and the genuinely urgent alerts are the ones that suffer.
The mechanism that keeps it honest is reviewing routing decisions after every incident — both directions. Something that paged and needed no action becomes a ticket. Something that was a ticket and should have woken someone becomes a page. Alerting is a system that decays without maintenance, and this review is the maintenance.