Service level objective
SLO / reliability target / attainment goal
A service level objective is a target value for a measured part of a service, such as 99.9% of requests succeeding over four weeks. It sets the error budget, the failures it can absorb, which decides when new releases ship and when reliability work comes first.
Google's site reliability engineering book builds the term in three layers. A service level indicator, or SLI, is a carefully defined measure of one part of the service, such as how fast requests are answered or how many fail. The SLO is the target value for that measure. A service level agreement, or SLA, is a contract with users that includes consequences for meeting or missing the SLOs it contains.
The book gives a quick test for telling them apart. Ask what happens if the target is missed. When there is no explicit consequence, the number is almost certainly an SLO. The book recommends keeping a tighter internal SLO than the one advertised to users, which leaves room to fix chronic problems before users see them. It calls insisting that SLOs be met 100% of the time unrealistic and undesirable. Instead, it allows an error budget, a rate at which the SLOs can be missed, and uses that budget to decide when to roll out new releases.
Google's example error budget policy defines the budget as 1 minus the SLO. A service with a 99.9% SLO that receives 1,000,000 requests in four weeks has a budget of 1,000 errors. Under that policy, a service over budget for the preceding four weeks halts all changes and releases except security fixes and top-priority bugs. Any single incident that uses more than 20% of the budget requires a postmortem. The policy explains the focus on releases: changes cause roughly 70% of Google's outages.
What counts as a failure decides the number. In Amazon CloudWatch, a period-based SLO judges the service one short period at a time, and an unhealthy period counts in full against the budget. With a 99% goal, a 30-day interval and 1-minute periods, 42,768 of the month's 43,200 minutes must be healthy. CloudWatch Application Signals' built-in availability measure treats 4XX responses as successful, and scheduled maintenance can be excluded from the count. A burn rate above 1 means the budget is being spent fast enough that the SLO may fail.
In practice
A developer builds a customer portal for an insurance agency and agrees to a 99.9% availability SLO over four weeks. The portal receives 200,000 requests in that window, so the error budget is 200 failed requests. One bad release produces 60 errors in an afternoon, which spends 30% of the budget in a single incident. Under a policy like Google's example, that incident calls for a postmortem. The figures are a worked example.
Not the same as
- Uptime guarantee
- An uptime guarantee is a service level agreement, a contract that includes consequences for missing the SLOs it contains, such as a rebate or a penalty. The SLO is the target itself, and it carries no explicit consequence on its own.
Why it matters to you
A reliability percentage on a software proposal says little until it names the measure, the time window and the exclusions. An agreed SLO with an error budget gives the business and its developer a shared rule for when new features wait and stability work comes first. Any money owed for a miss lives in a separate agreement, covered under uptime guarantee.
What to ask or check
- 01What does your SLO measure, over what time window, and what target has been set?
- 02Which errors count against the budget, and are maintenance windows excluded?
- 03What happens to new feature work when the error budget runs out?
- 04Is the internal SLO tighter than any figure promised to the business in the contract?
What people get wrong
That a missed reliability target is a breach of contract. Google's SRE book says people who talk about an SLA violation are almost always talking about a missed SLO, and a target with no explicit consequence is almost certainly an SLO.
Red flags
- A reliability target of 100%, which Google's SRE book calls unrealistic and undesirable.
- A stated reliability target with no written policy for what happens once the error budget runs out.