SLI, SLO, SLA: the reliability vocabulary every team should get right
SLIs, SLOs, and SLAs get used interchangeably and mostly wrong. Here's what each one means, how they stack, and how to set targets you can actually defend.
Three acronyms — SLI, SLO, SLA — turn up in every reliability conversation, usually used interchangeably and usually wrong. They aren’t synonyms. They stack: one is a measurement, one is a goal, one is a promise. Getting the distinction right is what turns “we should be more reliable” into something you can track, budget, and defend.
SLI — the thing you measure
An SLI (Service Level Indicator) is a quantifiable signal of how your service is actually doing: the percentage of requests served under 500 ms, the percentage of checks that return a correct response, availability over a window. A good SLI reflects what a user feels — not internal noise like CPU load. If a number wouldn’t change how a customer experiences the product, it’s a metric, not an SLI.
SLO — the target you hold yourself to
An SLO (Service Level Objective) is the internal goal for an SLI over a period — for example, “99.9% of checks succeed over 30 days.” It’s a decision, not a law of physics, and it should be a target you can realistically hit on a bad month, not just a good one.
The gap between 100% and your SLO is your error budget. At 99.9%, you have roughly 43 minutes of failure per month to spend. Spend it deliberately — on deploys, migrations, and experiments — and when it runs out, slow down and stabilize. Error budgets turn reliability from an argument into arithmetic.
SLA — the promise with consequences
An SLA (Service Level Agreement) is an external, contractual promise, usually backed by penalties such as service credits if you miss it. The golden rule: always set your SLA looser than your SLO. If you promise customers 99.9% but target 99.95% internally, you get an early-warning margin before a miss becomes a breach.
Setting them without overreaching
- Start from what users feel — availability, latency, correctness — and derive SLIs from that.
- Hit an SLO internally for a full quarter before you ever promise it in an SLA.
- Measure honestly: check often enough to catch short outages, confirm from multiple regions, and count correct responses, not just any
200. - Review targets quarterly. An SLO nobody revisits quietly becomes fiction.
The bottom line
SLIs measure, SLOs target, SLAs promise — in that order. Skip the SLI and your SLO is a guess; skip the SLO and your SLA is a gamble. Nail the vocabulary and reliability stops being a vibe and becomes something you can put a number on.
Start with an SLI you can trust. Explore website monitoring →
