Short version: an SLI is a measurement (e.g. the percentage of successful requests), an SLO is the internal target for that measurement (e.g. 99.9% over 30 days), and an SLA is the contractual promise you make to customers — usually a looser number than your SLO, with penalties if you miss it. You measure SLIs, you manage to SLOs, and you're held to SLAs. The three stack on top of one another:
These three acronyms get used interchangeably, but they describe different things aimed at different audiences. Getting them straight is the foundation of any reliability conversation. The framing below follows Google's SRE practice, documented in the SRE workbook chapter on implementing SLOs.
SLI — Service Level Indicator
An SLI is a quantitative measure of some aspect of your service. The best SLIs reflect what users actually experience, expressed as a ratio of good events to valid events. Common ones:
- Availability: successful requests ÷ total valid requests.
- Latency: the share of requests served faster than a threshold (e.g. 95% under 300 ms).
- Uptime: the share of time a monitored endpoint is reachable from outside.
The defining property of a good SLI is that it moves when users hurt. "CPU usage" is a metric, not a good
SLI — users don't feel CPU directly. "Checkout success rate" is a good SLI, because when it drops,
someone is failing to buy something. A useful discipline is to write each SLI as an explicit
specification: the proportion of HTTP GET requests to /api/* that return a non-5xx status within
300 ms, measured at the load balancer. That precision is what makes the number defensible later.
SLO — Service Level Objective
An SLO is the target you hold an SLI to, over a window. "99.9% availability over a rolling 30 days" is an SLO. SLOs are internal: they're how your team decides whether reliability is good enough to keep shipping features, or whether you should slow down and fix things.
The art is picking a number that's achievable and meaningful. Set it too low and users suffer; set it to 100% and you'll never ship anything, because the only way to never fail is to never change. The SRE workbook is blunt about this: 100% is the wrong reliability target for basically everything, because the cost of the last fraction of a nine is enormous and users usually can't even tell the difference.
SLA — Service Level Agreement
An SLA is the promise you make to customers in a contract, with consequences — often service credits — when you break it. Crucially, your SLA should be looser than your SLO.
If you operate to a 99.9% SLO internally, you might promise customers 99.5% in the contract. That gap is deliberate headroom: it means you can miss your internal target, notice, and fix it before you're in breach of a legal commitment that costs money. A team whose SLA equals its SLO has no margin for error — the first bad month is a breach. So the ordering is almost always: SLA target < SLO target, with the SLI being the shared measurement underneath both.
Error budgets tie them together
The gap between your SLO and 100% is your error budget — the amount of unreliability you're allowed to spend in a window. This is the single most useful idea in the whole framework, because it turns reliability from an argument into arithmetic.
Worked example. Say your SLO is 99.9% availability over 30 days.
- Allowed unreliability = 100% − 99.9% = 0.1%.
- Window = 30 days = 30 × 24 × 60 = 43,200 minutes.
- Error budget = 0.1% × 43,200 = 43.2 minutes of downtime per 30 days.
That's your budget. Every minute of real downtime — a bad deploy, a failed migration, a provider incident — draws it down. Spend it deliberately: ship risky changes while you have budget; when it's nearly gone, freeze risky work and stabilize until the window rolls forward and the budget refills. The same SLO over a full 365-day year allows about 8 hours 45 minutes.
Different SLO levels translate to very different budgets:
| SLO | Error budget / year | Error budget / 30 days | | ------- | ------------------- | ---------------------- | | 99% | ~3d 15h | ~7h 12m | | 99.9% | ~8h 45m | ~43m | | 99.99% | ~52m | ~4m 19s | | 99.999% | ~5m | ~26s |
The error budget reframes the classic dev-versus-ops fight. Instead of "ship faster" versus "be more stable," there's a shared number: while budget remains, velocity wins; when it's spent, reliability wins. Nobody has to relitigate it each time.
How they fit together
| Term | What it is | Audience | Example | | ---- | ------------------ | ----------------- | ------------------------ | | SLI | A measurement | Engineering | % of successful requests | | SLO | An internal target | Engineering | 99.9% over 30 days | | SLA | A customer promise | Legal / customers | 99.5%, or credits apply |
A simple way to remember the relationship: the SLI is the speedometer, the SLO is the speed limit you set for yourself, and the SLA is the speed at which you actually get a ticket. You want your self-imposed limit (SLO) to be stricter than the ticketing threshold (SLA), so you have room to slow down before it costs you.
Why measurement granularity matters here
Every one of these depends on an SLI you can actually trust, and an SLI is only as good as the measurement behind it. If your monitor checks every 30–60 seconds, a brief outage is either invisible or smeared across the polling window — which means your availability SLI is approximate, and any SLO or SLA built on it inherits that fuzziness. If a customer disputes an SLA credit, "down for about a minute" is not a position you want to defend.
Finer checks make the number defensible. PingInsight's intervals reach 5s on Business and 1s on Enterprise, with every probe stored against a millisecond timestamp, so the availability you report is the availability that happened — not a rounding of it.
Where to go next
- See exactly how much downtime each target allows in the uptime calculator.
- Pair SLOs with the response side in MTTR, MTTD, MTBF and MTTA.
- Read why second-by-second monitoring matters for the measurement-precision angle.