In this post
What is an SLI?
A number that reflects user experience, for example the proportion of requests answered successfully, or the proportion answered within a set time. A good one measures what users feel, not what is easy to count.
What is an SLO?
A target for an SLI over a period, for example “99.9% of requests succeed over 30 days”. It is an internal goal for the team and is not the same as a contract with a customer, which is usually looser.
What is an error budget?
It is the gap between perfect and the target. A 99.9% objective leaves 0.1% of requests allowed to fail, which over a 30-day month is about 43 minutes of full unavailability if measured by time. That allowance is what the team may spend on risk.
How is the budget used?
While budget remains, the team ships changes at the normal pace. When it is nearly spent, risky releases slow down and reliability work moves up the list. When it is overspent, feature releases stop until it recovers.
Why not aim for 100%?
It is unreachable, and chasing it blocks every change, since any change carries some risk. A target slightly below what users actually need leaves room to improve the product.
How should you alert on an SLO?
Alert on how fast the budget is burning rather than on every error. A fast burn pages someone at once, and a slow burn opens a ticket, so isolated errors do not wake anyone for nothing.
Sources and further reading
- Google. Site Reliability Engineering, “Service Level Objectives”. sre.google/sre-book/service-level-objectives/.
- Google. The Site Reliability Workbook, “Implementing SLOs”. sre.google/workbook/implementing-slos/.
IICTP is an independent technical credentialing body.