SLI, SLO and SLA

Definition

• SLI — a service level indicator: a measured quantity. Proportion of requests served successfully under 300 ms.
• SLO — a service level objective: the internal target for that indicator. 99.9% over 28 days.
• SLA — a service level agreement: the external contract, with financial consequences. Always looser than the SLO, so you breach your own target long before you breach a customer's.

Why the error budget is the whole point

An SLO of 99.9% grants an error budget of 0.1% — roughly 43 minutes of failure per 28 days. That budget converts reliability from an argument into an accounting exercise:

• Budget remaining → ship features, take risks, deploy on Friday.
• Budget exhausted → stop feature work, fix reliability, freeze risky changes.

This is the mechanism that makes an SLO more than a number on a dashboard. Without a consequence, "we should be more reliable" competes with "we should ship faster" every sprint and loses in a different way each time depending on who is in the room. With a budget, the trade is decided in advance and enforced by data.

It also legitimises spending the budget. A team with budget remaining should be moving faster, and 100% reliability is not the goal — it is a signal of over-investment in reliability at the expense of everything else.

Choosing good SLIs

• Measure what the user experiences, at the point they experience it. Server-side latency excludes DNS, TLS, the network and rendering — most of what the user perceives.
• Prefer a ratio of good events to valid events, which is comparable across load levels in a way an average never is.
• Use percentiles, never averages. An average hides the tail entirely, and the tail is where the experience lives.
• A handful per service. Availability, latency, and where relevant correctness or freshness. Ten SLIs is a dashboard, not an objective.

Industry example

The SLO and error budget framing comes from Google's site reliability practice, and the part most often lost in adoption is the organisational contract. The budget only works if the product organisation has genuinely agreed that exhausting it stops feature work. Adopted as a metric without that agreement, it becomes another dashboard nobody acts on, and the practice is blamed for not working.

Failure scenarios

• An SLO set at 99.99% by aspiration, requiring architecture nobody funded, so it is permanently breached and permanently ignored.
• Measured server-side, so the SLO is green while users suffer.
• No agreed consequence for exhaustion.
• One SLO for a whole estate, rather than per user-facing journey.
• SLA tighter than the SLO, which means the first internal warning is a customer credit.

Interview question

"Your service has exhausted its error budget in week two of a 28-day window. What actually happens next?"