The RED and USE methods say what to measure. This lesson is about a different, harder question those frameworks don't answer on their own: how good does the number actually need to be, and who decides that — turning a vague feeling of "reliable enough" into a specific, negotiated, checkable target.
3 min read
Lesson 3's RED metrics give a service its request rate, error rate, and latency distribution — but "error rate: 0.3%" is neither obviously fine nor obviously alarming on its own. Without an agreed target, every conversation about whether a service is "reliable enough" becomes a subjective argument instead of a checkable fact.
A Service Level Indicator (SLI) is a precisely-defined measurement of one aspect of user-facing behavior — not just any metric, but specifically one chosen because it reflects what a real user actually experiences:
SLI: percentage of requests to /checkout that return within 500ms
and don't return a 5xx status
This is more specific than "average latency" or "error rate" in isolation — it's a single number designed to answer "was the user's experience acceptable," combining both latency and correctness into one checkable definition.
A Service Level Objective (SLO) is the target value for an SLI, over a defined time window:
SLO: 99.9% of requests to /checkout meet the SLI above,
measured over a rolling 30-day window
99.9% (three nines) sounds close to 99.99% (four nines), but the difference is roughly 43 minutes of allowed downtime per month versus roughly 4 minutes — an order of magnitude, and each additional nine typically costs disproportionately more engineering effort to achieve. Choosing the right target is a real trade-off, not a default to maximize blindly.
A Service Level Agreement (SLA) is an SLO with a consequence attached externally — often a contractual, customer-facing commitment with a financial penalty for missing it. An SLO is typically set stricter than the corresponding SLA specifically to leave margin: missing the internal SLO is a signal to investigate, while missing the external SLA is already a customer-facing, potentially costly failure — the gap between the two is deliberate breathing room, not redundancy.
An error budget reframes the SLO as an allowance rather than a ceiling to avoid: a 99.9% SLO over 30 days literally permits up to 43 minutes of the SLI failing during that window, and that budget is a real resource a team can deliberately choose to spend.
This is the actual, practical value of the whole framework: when the error budget for a given period is nearly exhausted, that's a concrete, pre-agreed signal to slow down risky deploys and prioritize reliability work — and when there's budget remaining, it's explicit permission to ship features and take on normal deployment risk without needing to re-litigate "are we being too risky" as a subjective debate each time.
Without an error budget, teams tend toward one of two dysfunctions: treating every single failure as an emergency (burning out on-call engineers over blips well within any reasonable target), or ignoring reliability entirely until a major outage forces a reckoning. An error budget makes the actual trade-off explicit and pre-negotiated: a small, budgeted amount of unreliability is not just tolerated but expected, freeing a team to move fast within that budget — while giving a concrete, objective trigger (budget exhaustion) for when to deliberately slow down, instead of relying on someone's subjective judgment call in the moment.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. What is the difference between an SLI and an SLO?
2. What does an error budget actually give a team permission to do?
3. Why is an SLA typically set less strict than the corresponding internal SLO?
Observability & Monitoring