30.6 How do you alert without noise?

In the car: If the "check engine" light came on every time you went over a speed bump, you'd tape over it, and miss the day it mattered. Good warning lights are rare, clear and always mean "do something".

In the system: Bad alerting burns people out and hides real problems. Principles:

• Page on symptoms users feel, not on causes. "Checkout error budget burning fast" is worth waking someone; "CPU at 85% on one server" usually isn't (it may be fine, and if it isn't, the symptom alert will fire).
• Every page must be actionable and urgent. If the right response is "look at it tomorrow", it's a ticket, not a page.
• Use SLO burn-rate alerts. The Google SRE Workbook recommends multiwindow, multi-burn-rate alerts. For example, page when the burn rate is at least 14.4 over the last hour (2% of a 30-day budget gone in an hour) and still that high over the last 5 minutes (so it stops paging once the problem is fixed); open a ticket for slower burns over longer windows.

In the chapter's code: a 2% error ratio over the hour and 3% over the last 5 minutes pages; the same hour but only 0.05% in the last 5 minutes (already recovered) doesn't; a slow 0.3-0.4% burn doesn't page either (it's a ticket).

More habits:

• Route by ownership: the team that owns checkout gets checkout pages.
• Group and deduplicate: one incident, one page, not fifty.
• Review alerts regularly: delete or downgrade any alert that fired without needing action.
• Link every alert to a runbook and a dashboard.

Memory code: "A warning light should mean 'stop now', never 'speed bump'."

---