SLI, SLO & SLA | System Design Interview Handbook

🎯

The Three Terms

measurement, target, contract

Three nested terms, easy to confuse and important to keep straight. An SLI is the measurement, an SLO is the target you set for it, and an SLA is the contract you promise a customer, with penalties if you miss.

  SLI  ── Indicator: the raw measurement
          "p99 request latency", "fraction of requests that succeed"

  SLO  ── Objective: your internal target for that SLI
          "99.9% of requests succeed in < 300ms"

  SLA  ── Agreement: the external contract, with money attached
          "99.5% uptime or you get a refund"

  Rule: SLA is ALWAYS looser than SLO.
        You promise customers less than you aim for, so an SLO miss
        is an internal warning — not yet a contract breach.

💡

The relationship is the exam question. The SLA is deliberately looser than the SLO: you target 99.9% internally but only promise 99.5% externally, so there's a buffer. When you breach the SLO you get an early warning and time to react before you ever breach the SLA and owe a refund. Getting the ordering backwards is the classic mistake.

🔬

Choosing SLIs

measure what users feel, not what machines do

The point of an SLI is to capture the user's experience, so measure things users feel: did the request succeed, how long did it take at the edge. Don't measure machine internals like CPU — a server at 90% CPU serving every request in 50ms is fine, and a server at 20% CPU timing out is not.

ℹ️

Pick few and meaningful over many and noisy. Request success rate and latency at the edge cover most services; a wall of machine metrics buries the signal that a user is actually hurting. CPU and memory are useful for debugging and capacity, but they're causes, not symptoms — they don't belong in an SLI (Telemetry).

9️⃣

The Nines

each one multiplies the cost

Availability is quoted in nines, and each extra nine shrinks your allowed downtime by 10× — and multiplies the cost to achieve it. Know the rough downtime budgets.

Availability	Downtime / month	Downtime / year
99% (two nines)	~7.2 hours	~3.65 days
99.9% (three nines)	~43 minutes	~8.8 hours
99.99% (four nines)	~4.3 minutes	~53 minutes
99.999% (five nines)	~26 seconds	~5.3 minutes

⚠️

Composite availability is the trap: serial dependencies multiply. If a request needs five services each at 99.9%, the end-to-end availability is 0.999⁵ ≈ 99.5% — worse than any single component. Every hard dependency you add drags the whole system's number down. This is a concrete argument for fewer dependencies, graceful degradation, and not chasing more nines than the product needs (Resilience).

💰

Error Budgets

reliability as arithmetic

The error budget is the clever inversion: 100% minus your SLO is a budget you're allowed to spend. A 99.9% SLO means 0.1% of requests are permitted to fail — that headroom is currency for shipping features, running experiments, and taking risks.

  SLO 99.9%  ──▶  error budget = 0.1% of requests may fail

     budget remaining ─▶ ship freely, deploy, experiment, take risks
     budget exhausted ─▶ FREEZE features, stop risky deploys,
                          spend the sprint on reliability until it recovers

  turns "how much reliability?" from an argument into a number both
  the SRE and the product team can read off the same dashboard.

This dissolves the perennial fight between "ship faster" and "be more reliable." While budget remains, product ships. When it's spent, the team stops feature work and fixes reliability until the budget recovers. Reliability stops being a matter of opinion and becomes arithmetic both sides read off the same number.

🚨

Alerting

symptoms, not causes

Alert on symptoms users feel — the SLI breaching its target — not on causes like high CPU. A CPU alert fires when nothing is wrong and stays silent when something is; an SLI alert fires exactly when users are hurting. Burn-rate alerts refine this: page when you're consuming the error budget fast enough to exhaust it soon, so severity scales with how quickly things are degrading.

⚠️

Alert fatigue is a real outage cause. A team drowning in noisy, non-actionable alerts learns to ignore them, and the one that mattered gets muted with the rest. Every alert should be actionable and tied to user impact. Fewer, symptom-based, budget-aware alerts beat a wall of cause-based ones that cry wolf.

📋

Quick Reference

terms, nines, and budget

Term	Is	Example
SLI	The measurement	p99 latency, success rate
SLO	Internal target	99.9% < 300ms
SLA	External contract (penalties)	99.5% or refund — looser than SLO

Nines	Downtime / month
99%	~7.2 hours
99.9%	~43 minutes
99.99%	~4.3 minutes
99.999%	~26 seconds

ℹ️

The one-liners to keep ready. SLI measures, SLO targets, SLA promises — and the SLA is always looser than the SLO. Measure what users feel, not CPU. Each nine costs 10× and serial dependencies multiply failure, so don't chase more nines than the product needs. Error budget = 100% − SLO; spend it on velocity, freeze when it's gone. Alert on symptoms and burn rate, and guard against alert fatigue.