Filter concepts by levelShowing all levels.

System Design · SLIs, SLOs, SLAs and Error Budgets

SLIs, SLOs, SLAs and Error Budgets

The measured number, the internal target, the external promise, and the budget that connects them to shipping speed

  • SLI · SLO · SLAmeasured · internal target · external contract
  • Four common SLIssuccess rate, p95 latency, queue age, freshness
  • Error budget(1 − SLO) × time window
  • Drives velocityhealthy budget ships faster, low budget freezes

1.SLI, SLO and SLA

An SLI is the actual measured number (e.g. 99.95% of requests succeeded). An SLO is the internal target for that number (e.g. "keep it above 99.9%"). An SLA is the externally committed version of that target, usually with a financial or contractual consequence for missing it.

Key features

  • SLI (Service Level Indicator): the actual measured value — e.g. 99.95% success rate this week
  • SLO (Service Level Objective): the internal target for an SLI — e.g. "keep success rate above 99.9%"
  • SLA (Service Level Agreement): an externally committed SLO, usually with a penalty for missing it
  • SLOs are set stricter than SLAs, so an SLO breach gives warning before an SLA breach happens
  • Every SLA needs an SLI behind it; not every SLI needs an SLA (internal-only services often skip it)

SLI vs SLO vs SLA

SLI vs SLO vs SLA
TermWhat it isAudienceExample
SLIthe measured numberengineering99.95% success rate, measured this week
SLOthe internal target for that numberengineering, productkeep success rate ≥ 99.9%
SLAthe externally committed version, with consequencescustomers, legal99.5% uptime or a service credit
SLA < SLO <= SLI — buffer at every layer

SLI: 99.93%

the measured fact, this month

SLO: 99.9%

internal target — engineering's early warning

SLA: 99.5%

external contract, with a service credit if breached

  1. SLI: 99.93% — the measured fact, this month
  2. SLO: 99.9% — internal target — engineering's early warning
  3. SLA: 99.5% — external contract, with a service credit if breached

Command

text
SLI = the measured value            (fact)
SLO = the internal target for it    (goal)
SLA = the external, contractual SLO (promise + penalty)

SLA target  <  SLO target  <=  actual SLI (healthy state)

SLI = the measured fact. SLO = the internal target. SLA = the external, consequence-bearing promise. SLO is set stricter than SLA.

2.Common SLIs: success rate, latency, queue age, freshness

Four SLIs cover most services: request success rate (did it work), p95 latency (was it fast enough for most users), queue age (is a background system keeping up), and data freshness (is what a reader sees current enough to be useful).

Common SLIs

Common SLIs
SLIWhat it measuresCatches
Request success rate% of requests returning a non-error responseoutright failures, 5xx errors, crashes
p95 latencythe latency 95% of requests are at or belowa service that works but is too slow
Queue agehow long the oldest unprocessed item has waiteda background worker falling behind
Data freshnesshow old the data being served isstale reads from a lagging replica or cache
Three green tiles, one ongoing outage

A notification service during a 45-minute backlog. Success rate and latency measure the call that accepts the work, not the work.

  • Four dashboard tiles for a notification service.
  • Success rate 99.98 percent — green, looks excellent.
  • p95 latency 120ms — green, looks excellent.
  • Queue age 45 minutes — red, the real failure.
  • Data freshness not applicable for this service.
  • Below: the first two measure the call that enqueues work, and neither measures whether the work was ever done.

Command

text
success rate  = non-error responses / total responses
p95 latency   = the latency value at the 95th percentile
queue age     = now - enqueued_time(oldest unprocessed item)
data freshness = now - last_updated_time(the data being read)

Success rate catches errors, p95 latency catches slowness, queue age catches a falling-behind background system, freshness catches stale reads — track more than one.

3.Error budgets and release velocity

An error budget is the amount of failure an SLO allows — 100% minus the SLO, over a time window. Spending it fast (a bad release, an incident) means slowing down and stabilizing; having budget left means it is safe to ship faster and take more risk.

Key features

  • Error budget = (1 − SLO) × time window — the allowed downtime/failure for that period
  • A 99.9% monthly SLO permits about 43.2 minutes of failure that month
  • Every incident, failed deploy or degraded period spends from the budget
  • A healthy remaining budget justifies faster releases and more risk
  • A nearly exhausted budget justifies a release freeze and a shift to stability work

Error budget by SLO, 30-day window

Error budget by SLO, 30-day window
SLOMonthly error budgetMeaning
99.9%~43.2 minutesroom for one moderate incident a month
99.95%~21.6 minutesroom for one short incident a month
99.99%~4.3 minutesalmost no room — needs near-zero-downtime deploys
A 99.9% SLO's ~43.2-minute monthly budget, spent
  1. Week 1

    No incidents

    remaining: 43.2 min

  2. Week 2

    20-minute outage

    remaining: 23.2 min

  3. Week 3

    18-minute outage

    remaining: 5.2 min

  4. Week 4

    Budget nearly gone

    freeze non-critical releases

  1. Week 1: No incidents — remaining: 43.2 min
  2. Week 2: 20-minute outage — remaining: 23.2 min
  3. Week 3: 18-minute outage — remaining: 5.2 min
  4. Week 4: Budget nearly gone — freeze non-critical releases

Command

text
error budget = (1 - SLO) × time_window

remaining budget = error budget - time_spent_out_of_SLO

remaining budget low  -> freeze risky releases, focus on stability
remaining budget high -> safe to ship faster, take more risk

Error budget = (1 − SLO) × time window. Spend it on incidents; a healthy remaining budget justifies shipping faster, a low one justifies a release freeze.

Remember

  • SLI = the measured fact. SLO = the internal target. SLA = the external, consequence-bearing promise.
  • Common SLIs: request success rate, p95 latency, queue age, data freshness — each catches a different failure mode.
  • Error budget = (1 − SLO) × time window — a 99.9% monthly SLO permits ~43.2 minutes of failure.
  • A healthy remaining budget justifies shipping faster; a nearly exhausted one justifies a release freeze.

Pro tip

  • Set the SLO stricter than the SLA — the gap is the early-warning buffer before a contractual breach.
  • Track more than one SLI: success rate and latency both stay green while a background queue silently falls behind.

Next up

  • Basic architecture patterns
  • Monolith vs modular monolith vs microservices

Sources

  • System Design Primer — github.com/donnemartin/system-design-primer
  • Checked 2026-08-21

Spotted a mistake on this page? Tell us.

ReadSheet