You can understand the core of this in one idea: perfect reliability is the wrong target, and once you accept that, a lot of arguments get easier. If you’re technical but new to how reliability is run as a discipline, start here.

What an SLO is

An SLO — a service level objective — is a number you commit to for how reliable a service will be, over a window of time. “99.9% of requests succeed, measured monthly.” That’s it. It looks modest, but every word is load-bearing: it names what you’re measuring (successful requests), how good it has to be (99.9%), and over what period (a month).

The number is deliberately not 100%. That’s the part that surprises people. An SLO isn’t an aspiration you’re apologizing for missing — it’s a decision that some small amount of failure is acceptable, on purpose, because chasing the last fraction of reliability costs far more than it’s worth and buys users nothing they’d notice.

To make an SLO meaningful you need one thing underneath it: an SLI, a service level indicator. That’s the actual measurement — the percentage of requests that returned successfully, the fraction served under 300 milliseconds. The SLI is what you observe; the SLO is the line you drew on it. If you can’t measure the SLI, you don’t have an SLO, you have a wish.

Why it exists

Reliability work has a natural failure mode: it becomes infinite. There’s always another nine to chase, another rare failure to engineer away. Left unbounded, that impulse consumes a team — every outage becomes a crisis, every quarter is spent gold-plating, and no one can say when reliability is “good enough” to stop and ship features instead.

SLOs exist to end that argument with a number everyone agreed to in advance. They convert “is the service reliable enough?” from a matter of opinion, argued fresh during every incident, into a matter of measurement. Either you’re meeting the objective or you aren’t, and the answer doesn’t depend on who’s in the room or how loud the last outage was.

The idea that makes it click: the error budget

Here’s where it turns from bookkeeping into something useful. If your SLO is 99.9% success, then 0.1% failure is allowed. That allowance has a name — the error budget — and the shift is to treat it as a resource you get to spend, not a threshold you fear crossing.

Say you’ve only used a third of the month’s budget. That’s slack, and slack is permission: ship the risky deploy, run the migration, push the change you’ve been sitting on. If instead you’ve burned the whole budget with a week to go, the budget is telling you to stop taking risks — freeze changes, shore things up, spend the rest of the month getting boring.

That reframes reliability from a source of blame into a shared account. Product and engineering stop arguing about whether to move fast or be careful; the budget answers it. Fast when there’s budget, careful when there isn’t. The number decides, so people don’t have to.

The distinctions that trip people up

An SLO is not an SLA. An SLA is a contract with a customer, with money or penalties attached when you miss. An SLO is an internal target, and it’s usually set stricter than any SLA — you want to notice trouble well before it becomes a bill. Confusing the two makes teams either far too anxious about an internal goal or dangerously casual about a contractual one.

More nines is not obviously better. Each additional nine — 99.9% to 99.99% — costs sharply more to deliver and is often invisible to users. The right SLO is the one that matches what users actually notice and need, not the highest number you can print. Picking a target is a judgment call about your service, not a race.

The budget only works if missing it changes behavior. An error budget you blow through with no consequence is just a chart. Its whole power is the agreement, made ahead of time, that running out means something concrete happens — a change freeze, a shift in priorities. Without that pre-committed response, you have the vocabulary of SLOs without the discipline.

Where to go deeper

Start by picking one service and writing a single honest SLI — the percentage of requests it serves successfully. Watch it for a month before you commit to an objective; you’ll learn what “normal” actually is, which is usually different from what you assumed. The instinct to protect here is the counterintuitive one: reliability isn’t the absence of failure, it’s failure kept small, expected, and boring enough that no one has to be a hero about it.