SLO Burn-Rate Alerts · GUIDE
A fixed "error rate above 1%" alert pages you for blips and misses slow leaks. Alerting on how fast the error budget is being spent fixes both. This is the method, with the arithmetic, so you can check any generated rule by hand.
A 99.9% SLO over 30 days allows 0.1% bad requests. Under a full outage that is 30 x 24 x 60 x 0.001 = 43.2 minutes. That number is the budget; everything else is how fast you spend it.
A burn rate of 1 spends exactly the whole budget by the end of the period. A burn rate of 14.4 spends it 14.4 times faster, so 2% of the budget goes in one hour. The general formula is burn = fraction x period / window.
| Severity | Budget spent | Long / short window | Burn rate (30 days) | Error ratio at 99.9% |
|---|---|---|---|---|
| page | 2% | 1h / 5m | 14.4 | 1.44% |
| page | 5% | 6h / 30m | 6 | 0.6% |
| ticket | 10% | 1d / 2h | 3 | 0.3% |
| ticket | 10% | 3d / 6h | 1 | 0.1% |
The alert fires only while the long window and the short window are above the threshold. The long window keeps a brief spike from paging; the short window lets the alert clear within minutes of the fix instead of an hour later.
The threshold is burn x (1 - SLO). At a 90% SLO the page threshold is 14.4 x 10% = 144%, and no error ratio exceeds 100%, so that alert can never fire. Low-traffic services have the opposite problem: if the short window expects under one failing request at the threshold, a single error flips it. The generator flags both.
Compute sum(rate(errors[W])) / sum(rate(total[W])) once per window as a recording rule, then compare the recorded series to the threshold in the alert. The generator emits seven recordings and four alerts.
It is the burn rate at which 2% of a 30-day error budget is spent in one hour: 0.02 x 720 hours / 1 hour = 14.4. For a 28-day period the same policy gives 13.44.
The long window filters out blips and the short window makes the alert stop firing soon after the problem is fixed. Requiring both gives fast detection with few false pages.