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.
