The three layers
- SLI — IndicatorA number you actually measure. "Percentage of requests returning 2xx within 300ms." Purely factual, no target attached.
- SLO — ObjectiveYour internal goal for that indicator. "99.9% of requests succeed within 300ms, measured monthly." Aspirational but binding on your team.
- SLA — AgreementA contractual promise to a customer, with financial consequences for missing it. Always looser than your SLO.
The ordering matters. You cannot set an objective for something you do not measure, and you should never promise a customer something you have not been quietly hitting internally for months.
Your internal objective should be meaningfully stricter than your contractual commitment. That buffer is what gives you warning before you owe anyone money. Promising exactly what you target means every bad month is a breach.
Choosing an SLI that means something
A bad indicator is one that can look healthy while users suffer. Server-side uptime is the classic example: your process can be running perfectly while a DNS misconfiguration makes it unreachable for everyone.
Good indicators are measured as close to the user as possible and combine availability with latency. A request that succeeds after nine seconds did not really succeed.
Error budgets
An SLO of 99.9% is also a statement that 0.1% unavailability is acceptable. Over thirty days that is roughly 43 minutes. That allowance is your error budget, and framing it as a budget changes how teams behave.
Budget remaining is permission to take risk. Ship the ambitious migration, run the load test in production, deploy on a Friday. Budget exhausted means the next few weeks are for stability work, and that decision is made by arithmetic rather than by whoever argues hardest.
- Budget healthy — ship features, take calculated risks
- Budget half spent — slow down, review recent changes
- Budget nearly gone — freeze risky deploys, prioritise reliability
- Budget blown — stability work only until the window resets
Why 100% is the wrong target
A 100% availability objective is not ambitious, it is incoherent. It implies infinite investment for the final fraction of a percent, forbids all planned maintenance, and ignores that your users reach you through networks and devices you do not control.
It also removes the ability to make trade-offs. If every second of downtime is unacceptable, you can never ship anything, because every deploy carries risk.
Measuring what you promised
If you publish an SLA, you need an independent record of your availability — ideally one measured from outside your infrastructure, because a customer disputing a claim will not accept your own servers as the source of truth.
Define the measurement method in the agreement itself: check frequency, what counts as a failure, whether partial outages count, and whether announced maintenance is excluded. Most SLA disputes come from these definitions being left vague.