SLOs, error budgets and burn-rate alerts
SLIs, SLOs and error budgets, and how multiwindow burn-rate alerts page on real risk to users.
Published 30 September 2026.
Threshold alerts ask if a number is too high right now. SLO-based alerts ask if you will miss your reliability target at the current rate. This approach pages less often. The pages that fire matter more.
The terms
- SLI (service level indicator): a measurement of service quality, usually a ratio of good events to all events, such as the share of HTTP requests that succeed or the share served in under 300 ms.
- SLO (service level objective): a target for an SLI over a window, for example 99.9% of requests succeed, measured over 30 days.
- Error budget: what the SLO allows to go wrong: at 99.9%, 0.1% of requests, or about 43 minutes of full downtime in a 30-day window.
- SLA (service level agreement): a promise to customers, usually with a penalty; SLOs are internal and normally stricter than any SLA, so you notice trouble before it costs money.
Burn rate
Burn rate measures how fast you consume the error budget relative to the rate that would exhaust it completely over the window.
- A burn rate of 1 uses the whole budget by the end of the window.
- A burn rate of 2 uses it in half the window.
- A burn rate of 14.4 over a 30-day window uses 2% of the budget in one hour.
A short outage that burns fast is urgent. A slow, steady leak is not urgent tonight, but will use the budget before the month ends. Burn-rate alerts catch both, with different urgency.
Multiwindow, multi-burn-rate alerts
The Alerting on SLOs chapter of the Google SRE Workbook reviews several designs. It recommends a specific setup for a 99.9% SLO over 30 days.
| Budget used | Long window | Short window | Burn rate | Action |
|---|---|---|---|---|
| 2% | 1 hour | 5 minutes | 14.4 | Page |
| 5% | 6 hours | 30 minutes | 6 | Page |
| 10% | 3 days | 6 hours | 1 | Ticket |
Each alert fires only when both windows exceed the burn rate. The long window confirms the problem is significant. The short window confirms it is still happening. So the alert resolves soon after the problem stops, not hours later.
Getting started
- Pick one user journey that matters, such as loading the dashboard or submitting a payment.
- Choose an SLI you can measure today, usually from load balancer or application metrics.
- Set an SLO slightly below your current performance. You can raise it later. A target you already miss will page constantly.
- Add burn-rate alerts using the table above as a starting point.
- Keep a few symptom alerts for gaps the SLO does not cover. This includes total outages of low-traffic services where the ratio is too noisy.
Tools
Several tools generate burn-rate alert rules from an SLO definition. The open source Sloth and Pyrra projects do this for Prometheus. Most observability platforms in the observability directory have SLO features built in.