SLI, SLO, SLA — three acronyms that sound interchangeable and aren't. Get them straight and the whole language of reliability engineering clicks into place, because almost every on-call and prioritisation decision traces back to these three numbers.
SLI — the measurement
A Service Level Indicator is a metric of how your service is actually doing: the percentage of requests served successfully, the 95th-percentile latency, uptime over a window. It's a raw number you measure, nothing more. Good SLIs reflect what users actually feel, not what's easy to graph.
SLO — the target
A Service Level Objective is the goal you set for an SLI: "99.9% of requests succeed over 30 days," "p95 latency under 200ms." It's an internal promise, and it's where the judgement lives — 100% is the wrong target for almost everything, because the last fraction of a nine costs more than it's worth.
SLA — the contract
A Service Level Agreement is a formal promise to a customer, usually with financial penalties if you miss it. Your SLA should always be looser than your SLO — you want to trip your own internal alarm (SLO) and fix things long before you breach the contract (SLA) and owe refunds.
The error budget ties it together
If your SLO is 99.9% success, the other 0.1% is your error budget — the amount of failure you're allowed to spend. Budget left over? Ship features faster, take more risk. Budget blown? Freeze risky changes and spend on reliability instead. It turns "how stable is stable enough?" from an argument into arithmetic.
Feel the SLA clock for real
Reliability targets stop being abstract the moment a deadline is ticking. In the simulator, every incident opens with an SLA timer and breaching it costs you — exactly the pressure that makes these trade-offs concrete. Run a live incident response shift, and if you're interviewing, rehearse the vocabulary with SRE interview practice or compare roles in SRE vs DevOps.