SLOs & Error Budgets

Ask most teams "how reliable should this service be?" and you'll get a religious answer: as reliable as possible. That answer is how reliability stays an ops afterthought — something engineers plead for after launches, in the language of fear. Google's SRE organization made one move that changed the whole conversation: treat reliability as a product decision, with a number on it, chosen deliberately and defended like any other feature trade-off.¹ This lesson gives you that vocabulary — three acronyms and one budget — and it's the vocabulary Principal interviews expect you to speak fluently.

Three letters, three different things

People blur SLI, SLO, and SLA constantly, and the blur is expensive — they belong to different owners and drive different behavior. Keep them apart:¹

The ordering matters: you measure an SLI, you target an SLO, and the business sells an SLA that sits looser than the SLO — your internal target trips first, so you're fixing things before you're writing refund cheques.¹ As an engineer you will rarely write SLAs; you will absolutely be expected to write SLIs and SLOs. One rule dominates everything else: a good SLI measures what users experience — a request they sent, a page they loaded — not a proxy that's merely easy to collect. CPU utilization is not an SLI; your server can be at 40% CPU while every user request fails.³

Why 100% is the wrong target

The counterintuitive core of the whole discipline: 100% is the wrong reliability target for basically everything.² Two reasons. First, past a certain point users cannot tell the difference — their phone, their Wi-Fi, their ISP fail more often than you do, and your extra nine disappears into that noise. Second, each additional nine costs roughly ten times more — and you pay for it in the currency you care most about: features you can't ship, because every deploy is a risk you can no longer afford.¹ Look at what the nines actually buy:

Read that table as a Principal: 99.999% means no human is in the loop — 26 seconds is less time than it takes to open a laptop. That's an architecture (automated failover, multi-region), not an aspiration, and it's why the right question is never "how reliable can we be?" but "what's the cheapest reliability our users will be happy with?"² The full nines table, the SLI menu, and the math live in this course's SLO cheat sheet — printable, keep it next to your monitor.

The error budget — the genius move

Here's where it stops being definitions and becomes an operating system. If your SLO is 99.9%, then 0.1% of events are allowed to fail. That allowance is your error budget — and the move is to treat it as a resource you spend, not a failure you apologize for.² Concretely: 10 million requests a month at a 99.9% SLO is a budget of 10,000 bad requests. Spend it on velocity — risky deploys, experiments, planned maintenance. A service comfortably inside its SLO with budget left over isn't "doing great"; it's underspending, and should be shipping faster.⁴

The Principal angle: negotiation, not pleading

Notice what the error budget really is: an org-alignment tool. Product is paid for velocity; reliability engineers are paid for stability — structurally opposed incentives that usually get resolved by politics, seniority, or who shouts loudest in the launch review.² The error budget replaces that with a self-policing contract: product agreed to the number, so when the budget is gone, the freeze isn't the engineers punishing anyone — it's the policy both sides signed. This is the lesson where reliability becomes something you negotiate — in a document, once — instead of something you plead for, in every meeting, forever. Walking into a room of product and engineering leads and brokering that number is leverage in its purest form, and it's a story promotion committees recognize instantly.

🧪 Lab: the SLO worksheet

This is the lab this whole module builds on — the same exercise Google's Customer Reliability Engineering team runs in its Art of SLOs workshop, pointed at a service you actually know.³ Pick one real service you own or know well and write a one-page worksheet:

1. The critical user journey — one sentence: who the users are and the one interaction that, if it breaks, makes them consider leaving.
2. Two SLIs, with exact measurement definitions — for each: where is it measured (client, load balancer, server?) and what precisely counts as a good event (which endpoints, which status codes, what latency threshold)?
3. A defensible SLO for each — the target and window, plus one "why this number" sentence tied to what users notice, not to what the dashboards currently show.
4. The monthly error budget it implies — in minutes or bad requests — and one sentence stating what the team does when it's exhausted.

Feedback loop: bring it back to me in chat. I'll review it against a Principal-level rubric — is each SLI measurable as specified, today (or does the worksheet honestly name the gap), is each SLO tied to user experience rather than current performance, and is the error-budget policy an actual decision rule someone could enforce on a bad Tuesday. This worksheet joins your evidence trail — Lesson 12 folds it into the promotion packet.

Check yourself — spend the budget

Three scenarios. Diagnose from the mental model — don't scroll up. Wrong picks stay live.