Burn Rate Alerting
Paging when the error budget is being consumed fast enough to matter, rather than when a component crosses a threshold.
A threshold alert on error rate fires the same way whether the service is briefly noisy or genuinely failing. Burn rate asks a different question: at this rate, when will the budget be gone?
Burn rate is the consumption rate relative to the budget. A burn rate of 1 exhausts the budget exactly at the end of the window; a burn rate of 14.4 exhausts a 30-day budget in about two days.
The standard arrangement uses multiple windows: a fast burn (very high rate over a short window) pages immediately, because something is badly wrong right now; a slow burn (a moderate rate over a long window) opens a ticket, because something is degrading steadily and will matter next week. Each alert is paired with a short window to confirm the condition still holds, which suppresses the firing on a blip that has already passed.
The effect is that dozens of cause-based alerts collapse into a handful of symptom-based ones, every page corresponds to real user impact, and alert fatigue drops sharply. It is the single highest-value change most alerting setups can make.