Concept · Requirements & scale
SLIs, SLOs and error budgets
Measure what users feel, set a target, and spend the slack on purpose.
Three related terms give reliability a number and a way to make decisions with it.
- SLI (service level indicator): a measurement of what users experience. "The fraction of checkout requests that succeed in under 500 ms."
- SLO (service level objective): the target for an SLI over a window. "99.9% of checkout requests succeed in under 500 ms, measured over 28 days."
- SLA (service level agreement): a contract with customers, with consequences (refunds, credits) if it's missed. Set SLAs looser than your SLOs so you have warning before you owe anyone.
Choosing good SLIs
Measure at the point closest to the user — the load balancer or the client — not CPU or memory on a server. Typical SLIs:
| Kind | SLI |
|---|---|
| Availability | Successful requests / valid requests |
| Latency | Requests faster than a threshold / all requests |
| Freshness | Records updated within N minutes / all records |
| Correctness | Jobs with correct output / all jobs |
Error budgets
An SLO of 99.9% means 0.1% of requests may fail: that's the error budget. Over 28 days with 100 million requests, it's 100,000 failed requests.
The budget turns reliability arguments into decisions:
- Budget left: ship features, run experiments, do risky migrations.
- Budget nearly spent: slow releases, prioritise reliability work.
- Budget burning fast: page someone.
Alert on burn rate
Instead of alerting on every error spike, alert when the budget is being spent too fast to last the window — for example, a burn rate that would exhaust 2% of the monthly budget in one hour. That catches real incidents quickly and ignores blips.
The Backend with Go roadmap's observability lesson shows how to collect these metrics; availability and the nines shows what the targets mean in minutes.