Skip to content
Detecting Failure

09.03 · Concept

SLIs, SLOs, and Error Budgets

Define an SLI and an SLO for one user journey and convert the target into a monthly error budget.

No video curated for this lesson yet

This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Deployment lesson by lesson; 29 of 56 have their video so far.

The written notes below cover this idea in full - you lose nothing by reading instead of watching.

SLIs measure user-visible reliability, SLOs set the target for those measurements, and error budgets turn the gap into an explicit allowance for failure. A good reliability target starts from one user journey, counts valid user outcomes, excludes irrelevant traffic, and converts the chosen target into permitted monthly failures or downtime.

What this lesson answers

  • how to define an SLI for checkout
  • how to calculate a monthly error budget
  • why not use average latency for SLOs

Notes

SLIs, SLOs, and Error Budgets — SLIs, SLOs, and error budgets exist to turn “is the service working for users?” into measurable reliability commitments; without them, teams argue from anecdotes, overreact to harmless failures, or miss real user-impacting outages.

Key Concepts: - An SLI is a numeric measurement of user experience, e.g. checkout success rate . - An SLO is a target for an SLI over a time window, e.g.

Common questions

What is the difference between an SLI and an SLO?
An SLI is the measurement, such as the proportion of valid checkout attempts that end in an order. An SLO is the target applied to that measurement over a chosen window, such as requiring that success rate to stay above a defined threshold over 30 days.
How do you calculate an error budget from an SLO?
Subtract the SLO from 100% to get the allowed failure rate. Apply that allowance to the volume or time window you care about. For example, a 99.9% target leaves a 0.1% budget, which can be expressed as permitted failed requests or permitted downtime.
Why should an SLI be based on a user journey?
Reliability targets should reflect what users experience, not just what internal systems report. A service can return 200 OK internally while the browser times out or the user never completes checkout. Measuring the journey outcome keeps the target tied to real impact.