An error budget says how much can break. This says when to shout about it: the burn-rateBurn rate: how fast you're spending the error budget relative to time. 1× drains it exactly over the SLO window; 14.4× drains it 14.4 times faster. thresholds that page you fast on a real fire, ticket you on a slow leak, and stay quiet on the noise between — the multi-window, multi-burn-rate recipe from the Google SRE workbook.
| Alert | BurnBurn rate: how fast you're spending the error budget relative to time. 1× drains it exactly over the SLO window; 14.4× drains it 14.4 times faster. | WindowsTwo rolling windows, both required over threshold at once: the long one proves the burn is significant, the short one lets the alert reset fast once it stops. | Fires aboveThe error-rate threshold the rule compares against — burn rate × error budget. The alert fires when the share of failing requests over the window climbs past it. | Budget burnedHow much of the whole SLO-window budget is spent by the time the long window trips — the 'is this worth waking someone' axis. Pages trip early, tickets later. |
|---|---|---|---|---|
| Fast pageWake someone now: a fast, severe burn. At 14.4× a total outage trips it in under a minute, and the high threshold means only a real fire pages. | 14.4× | 1h / 5m | > 1.44% | 2% |
| Slow pageWake someone now: a sustained, moderate burn the fast page's higher threshold would sleep through — slower to fire, but still urgent. | 6× | 6h / 30m | > 0.6% | 5% |
| Fast ticketFile a ticket, don't wake anyone: a slow leak draining the budget over hours — worth fixing in business hours, not at 3am. | 3× | 1d / 2h | > 0.3% | 10% |
| Slow ticketFile a ticket: the slowest burn that still threatens the budget — a 1× drip that would quietly exhaust it right by reset day if left alone. | 1× | 3d / 6h | > 0.1% | 10% |
Each alert needs both windows over threshold at once. The long window sets significance — how much budget burns before it fires — so a brief blip is ignored; the short window resets it fast once the burn stops, so it doesn't keep paging over a fixed incident. Pages catch fast, severe burns; tickets catch the slow leaks a page would sleep through.
Any two of burn rate, budget spent and window pin the third — the recipe behind the table above (2% over 1h ⇒ 14.4×). Detect is the worst case, a total outage; a partial burn trips proportionally slower. Resets within tracks the short window.
# Recording rules — swap http_requests_total and the 5.. matcher for your service
- record: job:slo_errors_per_request:ratio_rate1h
expr: |
sum(rate(http_requests_total{job="myjob", code=~"5.."}[1h]))
/
sum(rate(http_requests_total{job="myjob"}[1h]))
- record: job:slo_errors_per_request:ratio_rate5m
expr: |
sum(rate(http_requests_total{job="myjob", code=~"5.."}[5m]))
/
sum(rate(http_requests_total{job="myjob"}[5m]))
# Alert — both windows must exceed burn × budget at once
- alert: ErrorBudgetBurn
expr: |
job:slo_errors_per_request:ratio_rate1h > (14.4 * 0.001)
and
job:slo_errors_per_request:ratio_rate5m > (14.4 * 0.001)
labels:
severity: page
annotations:
summary: "99.9% SLO error budget burning at 14.4× over 1h / 5m"The recording rules precompute the failing-request ratio per window, so the alert reads two cheap gauges instead of re-deriving the rate twice — swap http_requests_total and the 5.. matcher for your own metric. Severity follows the workbook's 6× page/ticket boundary; relabel to taste.