Service Level Objectives and Error Budgets
The three terms, precisely
- SLI (indicator): a quantitative measurement of service behaviour, e.g. the proportion of HTTP requests served in under 300 ms, or the proportion of successful writes.
- SLO (objective): a target range for an SLI over a defined window, e.g. 99.9% of requests succeed over a rolling 28 days.
- SLA (agreement): a contract with a customer that includes consequences - refunds, credits, penalties - if breached. SLAs are usually looser than internal SLOs, so the team notices trouble before customers do.
Error budget = 1 − SLO. At 99.9% over 30 days the budget is 0.1% of the window, about 43 minutes of full outage equivalent (99.95% ≈ 21.6 min, 99.99% ≈ 4.3 min). The budget is spent by any unreliability, planned or not, which is why it works as a release-velocity lever.
Traps
- Setting an SLO at 100%. It leaves no budget, forbids all change, and cannot be measured meaningfully.
- Defining SLIs from server health (CPU, uptime) instead of user-visible behaviour (success ratio, latency). A healthy fleet can still serve errors.
- Averaging over a long window and missing short severe spikes; use rolling windows and multi-window burn-rate alerts.
- Forgetting an error budget policy: the budget is meaningless without a pre-agreed consequence (freeze releases, prioritise reliability work).
Worked example
The SLO is 99.9% success over 28 days. A bad deploy burns 0.3% of requests for 4 hours and then is rolled back. That single event consumes roughly three times a day's worth of a full budget in hours - well past a healthy burn rate. A multi-window alert (e.g. 2% of budget in 1 hour) fires long before the monthly budget is gone, so the team reacts while the budget still protects the roadmap.