Three terms, one hierarchy
SLI, SLO, and SLA are often used interchangeably, but they build on each other. An SLI is what you measure, an SLO is the target you set for that measurement, and an SLA is the promise you make about it to someone else, with consequences attached. Reading them in that order — indicator, objective, agreement — is the quickest way to keep them straight.
SLI: what you measure
A Service Level Indicator is a quantitative measure of some aspect of your service. Good SLIs describe the experience users actually have: the proportion of requests that succeed, the proportion served faster than a latency threshold, or availability measured from outside the system. A well-chosen SLI moves when users are unhappy and stays flat when they are not.
Pick a small number of indicators that map to real user pain. Measuring everything dilutes attention; measuring the request success rate and a latency percentile covers most services well.
SLO: the target you set
A Service Level Objective is a target value or range for an SLI over a window — for example, "99.9% of requests succeed, measured over a rolling 28 days". The SLO is internal: it is the line your team agrees to hold, the input to alerting, and the basis for deciding whether reliability work should take priority over new features.
A realistic SLO is one you can actually meet most of the time while still leaving room to ship. A target of 100% is not an objective — it is a promise to never take a risk, which stalls the product.
SLA: the promise with consequences
A Service Level Agreement is a commitment to a customer that includes what happens if you miss it, such as service credits. The crucial practice is to make the SLA looser than your internal SLO. If you promise customers 99.9% but hold yourselves to 99.95% internally, you get an early-warning margin: your own alerts fire well before you are anywhere near breaching the contract.
Not every service needs an SLA, but every service that customers depend on benefits from an SLO. The agreement is a business decision; the objective is an engineering one.
Where error budgets fit
An error budget is simply the inverse of an SLO: if the objective is 99.9%, the error budget is the remaining 0.1% — the amount of unreliability you are allowed to spend over the window. It reframes reliability as a resource rather than an absolute. While budget remains, you can ship and take measured risks; when it is exhausted, the sensible response is to slow risky changes and spend effort on reliability until you are back within target.
The budget turns "how reliable should we be?" from an argument into arithmetic, and gives product and engineering a shared, objective signal for when to push and when to steady.