SLI, SLO, and SLA are three layers of the same idea, reliability made concrete, and they stack: an SLI is a measurement, an SLO is your internal target for that measurement, and an SLA is the external promise about it, with consequences attached. Most confusion disappears once you see that each layer is built from the one below.
The Stack#
| What it is | Example | Audience | Breach consequence | |
|---|---|---|---|---|
| SLI (indicator) | A measured signal of service health | 99.92% of requests succeeded this month | Engineering | None; it is just data |
| SLO (objective) | The internal target for an SLI | Successful requests ≥ 99.9% per month | Engineering + product | Internal: freeze features, fix reliability |
| SLA (agreement) | The contractual promise to customers | 99.5% uptime or 10% service credit | Customers, legal | Refunds, credits, lawyers |
Two patterns worth noticing. The SLA is looser than the SLO: you promise customers less than you aim for internally, so the SLO breach is your early warning before money is on the line. And everything rests on the SLI: an objective over a signal you do not actually measure is fiction.
Good SLIs#
The useful SLIs are user-facing ratios, not machine stats: availability (good requests / total requests), latency (share of requests faster than a threshold, e.g. 95% under 300ms), and correctness/freshness where it matters. CPU usage is not an SLI; users do not experience your CPU, they experience whether the page answered.
Measure SLIs as close to the user as possible. A service that reports itself healthy while the load balancer in front of it is misrouting has a great internal number and a terrible real one; outside-in measurement closes that gap.
Error Budgets: Where This Becomes Useful#
A 99.9% monthly SLO implies a budget: 0.1% of requests (or about 43 minutes) are allowed to fail per month. That number turns reliability arguments into arithmetic. Budget mostly unspent: ship faster, take risks, do the migration. Budget burned: feature work slows, reliability work jumps the queue. It is the contract between "move fast" and "stay up" that both sides can read on a dashboard.
Setting Honest Targets#
- Start from measured reality, not aspiration: if you ran 99.85% the last quarter, a 99.99% SLO is theater
- Each added nine costs roughly 10x the effort; 99.99% is 4.3 minutes of error budget a month, which rules out human-speed incident response
- Set SLOs per journey (checkout stricter than search), not one blanket number
- Keep the SLA a notch below the SLO, and only sign SLAs you can measure and afford to breach
Limitations to Know#
- Averages hide breaches. A monthly availability average can look fine while one customer's region burned; slice SLIs by region and tier where it matters.
- Targets ossify. SLOs set once and never revisited drift away from what users actually need; review them when the architecture or the user base changes.
- An SLA without measurement is a liability. If the customer's monitoring is the only measurement, every dispute starts from their numbers.
Conclusion#
SLIs are what you measure, SLOs are what you aim for, SLAs are what you promise with penalties, and the error budget is the layer that turns them into day-to-day engineering decisions. Get the SLI honest and user-facing first; the rest is arithmetic and negotiation.
The measurement layer is exactly what ObserveOne provides: uptime and API checks measure availability and response time from outside, the way users experience it, and a public status page communicates the record, so your SLO dashboard and your customers' view of an incident come from the same numbers.