SLOs, SLIs and Error Budgets Explained

"Make it reliable" isn't a goal you can measure. Service level objectives turn reliability into a number that product and engineering can agree on.

The terms

• SLI (indicator) - a measurement of user experience, usually a ratio of good events to total events. Example: the share of checkout requests that succeed in under 1 second.
• SLO (objective) - the target for an SLI over a time window. Example: 99.5% over 28 days.
• SLA (agreement) - a contractual promise to customers, with consequences. Set it looser than your SLO.

Good SLIs

Availability: successful requests / all requests            (exclude 4xx caused by clients)
Latency:      requests faster than 500ms / all requests
Freshness:    reports updated within 1 hour / all reports

Measure as close to the user as practical, such as at the load balancer or in the client, rather than deep inside one service.

Error budgets

A 99.5% SLO means 0.5% of requests may fail. Over 28 days with 10 million requests, that's 50,000 failed requests: your error budget.

• Budget left: ship features, run experiments, take reasonable risks.
• Budget spent: slow down risky releases and prioritise reliability work until it recovers.

This turns arguments about "moving fast vs being careful" into a shared, data-driven decision.

Alert on burn rate

Instead of alerting on every error spike, alert when you're consuming the budget too fast:

Page:   budget burning 14x faster than sustainable over the last hour (and last 5 min)
Ticket: budget burning 3x faster over the last day

Fast burns page someone; slow burns create a ticket. This catches real problems quickly while ignoring brief blips.

Choosing a target

• 100% is the wrong target: it's impossible, and users can't tell 99.99% from 100% through their own network and devices.
• Each extra "9" costs much more effort. Start with what you achieve today and what users need.
• Pick a few SLOs for the most important user journeys (sign in, search, checkout), not one per microservice.