# SLIs, SLOs and error budgets

> Measure what users feel, set a target, and spend the slack on purpose.

Concept · Requirements & scale · https://levelcode.org/concepts/sli-slo-sla

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](https://levelcode.org/concepts/availability-and-nines) shows what the targets mean in minutes.