What is an SLO?
It is the number that wakes an engineer up on a Tuesday, days before the contract you signed would ever be broken.
SLO (service-level objective)
SLI (the metric an SLO targets)
An SLO, or service-level objective, is the internal reliability target a team sets for itself, measured on a metric called an SLI. It sits stricter than the SLA. That gap gives a team room to catch a problem before the external promise breaks.
Three terms sit in a ladder. Mixing them up is where most confusion starts. An SLI is the raw measurement: request latency, error rate, percentage of successful checkouts. An SLO is the target set on that SLI, decided internally: 99.95% of checkouts succeed in a rolling 30 days. An SLA is that same target, written into a contract with a consequence for missing it.
The SLO is always tighter than the SLA. If a contract promises 99.9% uptime, the team running the system usually targets 99.95% internally. That gap is not padding. It is room to catch a bad week before a customer has grounds to invoke the contract.
The error budget is what the gap is for
The space between 100% and the SLO is called the error budget. A 99.95% SLO on checkout success leaves 0.05% of checkouts free to fail before the target is at risk. That is not a bug tolerance. It is a planning number. It caps how much risk a team can spend on a deploy or a migration before reliability work has to take priority.
A team that has burned most of its budget for the month should slow down and stabilize. That holds even if the SLA is nowhere near breached. Setting the SLO tighter than the promise exists for exactly this reason. It creates a warning that fires early, instead of a client pointing at the contract after the fact.
We set SLOs against the SLA on every maintenance engagement. It is a real target tied to the metric that matters, not an uptime figure on a dashboard nobody checks. That metric might be checkout success, agent response latency, or a data pipeline finishing before the next job needs it.
- SLI measuredSuccess rate, latency, whatever the metric is.
- SLO checkedIs it still inside the internal target?
- Budget spentEach failure eats into the month's allowance.
- Threshold crossedBudget low. Ship less, fix more.
- Window resetsNew rolling period, budget refills.
The SLA only enters this loop as a hard floor. Week to week, the SLO and its budget are what actually decide the team's behaviour.
Common questions
01What is the difference between an SLA, an SLO, and an SLI?
An SLI is the measured metric. An SLO is the internal target set on that metric. An SLA is the same kind of target written into a contract, with a consequence for missing it. The SLI feeds the SLO, and the SLO sits tighter than the SLA so there is warning before the contract is at risk.
02What does error budget mean?
It is the amount of failure allowed under an SLO before the target is breached, usually expressed as a percentage over a rolling window. A 99.9% SLO on a 30-day window allows roughly 43 minutes of downtime in that window. Once the budget is spent, the priority shifts from shipping features to shipping stability.
03Does every system need an SLO?
Any system a team is actively responsible for keeping up benefits from one. It turns a vague sense of "seems fine" into a number someone can be paged against. A system with no SLA and no one on call for it usually does not need a formal SLO either.
04Who sets the SLO, us or the client?
We propose it, tied to the SLA and the metric that matters for that system. We agree it with the client before the maintenance contract starts, and revisit it if usage or risk tolerance changes.
