system-design · advanced

SLIs, SLOs, and Error Budgets

Quick answer

An SLI quantifies user-facing reliability. An SLO is the target for that SLI. An error budget is allowed unreliability (1 − SLO) used to decide when to ship versus stabilize.

Why this matters

Learning objectives

  1. Choose journey-based SLIs. 2. Set realistic SLOs. 3. Spend error budgets deliberately. 4. Alert on burn rate. 5. Avoid vanity metrics.

Explain like I am 5

If you may miss only 1 homework question in 1000, that tiny allowance is your budget for mistakes—and for trying new methods carefully.

Mental model

flowchart LR
  Journey --> SLI --> SLO --> Budget
  Budget --> Ship
  Budget --> Stabilize
TermExample
SLI% checkout 2xx within 300ms
SLO99.9% over 28 days
Budget~0.1% failures in the window

Core concepts

User journey SLIs

Prefer checkout/login success over CPU%.

Windows

Rolling 28-day windows are common; document them.

Multi-SLI

Separate availability and latency; do not hide slow success as "up".

Budget policy

When exhausted: slow releases, reliability focus, or renegotiate SLO.

Burn-rate alerts

Multi-window burn rates beat static thresholds.

Worked example

SLO 99.9%. Bad deploy burns half monthly budget → freeze noncritical deploys; hotfix only; restore budget before expanding flags.

Trade-offs

Tight SLOLoose SLO
High costMore user pain
Slower changeFaster change

Failure modes

ModeMitigation
Internal-only SLIsMap to journeys
Fantasy 99.999Cost model first
Budget ignoredWritten policy

Interview mode

Skeleton: "Journey SLIs, product-agreed SLOs, error budgets gate velocity versus reliability work."

Knowledge check

Allowed unreliability (1 − SLO) over a window

On-call headcount only

Cloud invoice total only

A synonym for QPS

By Shubham Jain

All articles

Shubham Jain · Learning Lab