SLOs, SLIs and Error Budgets Explained: Reliability Targets for Leaders

Short answer

SLIs measure what users experience, SLOs set targets for those measures, and SLAs are contracts with consequences. An error budget is the unreliability an SLO allows: while budget remains, ship; when it runs out, fix reliability first. Never target 100%. Start with one service, two or three user-facing SLIs and a modest target you can meet.

• 3 - terms to keep apart: SLI, SLO and SLA
• 43 min - downtime a 99.9% SLO allows over 30 days
• 0.1% - error budget at 99.9%: the room to take risks
• 100% - the target never to set

Service level objectives are how engineering and the business agree what “reliable enough” means. An SLI (service level indicator) measures something users care about, such as the share of successful requests. An SLO (service level objective) is the target for that measure. An error budget is the small amount of failure the target allows, and it turns reliability from an argument into a shared rule for when to ship and when to slow down.

SLI, SLO and SLA in plain English

TermWhat it isExampleSLI: service level indicatorA measurement of the service users experienceShare of checkout requests that succeed in under 500 msSLO: service level objectiveThe target for an SLI over a period99.9% of checkout requests succeed in under 500 ms over 30 daysSLA: service level agreementA contract with customers, with consequences if missedService credits if availability falls below 99.5% in a month

Keep internal SLOs stricter than external SLAs. The gap is your early warning: you can act on a missed SLO before you owe customers anything.

Why 100% is the wrong target

Google’s Site Reliability Engineering guidance is blunt: insisting that SLOs are met 100% of the time is both unrealistic and undesirable. Each extra “nine” costs far more than the last, users’ own networks and devices fail more often than a well-run service, and a team chasing perfection stops shipping. The right target is the lowest level of reliability that keeps users happy.

Availability SLODowntime allowed per 30 daysTypical use99%About 7 hours 12 minutesInternal tools, batch systems99.5%About 3 hours 36 minutesLess critical customer features99.9%About 43 minutesMost customer-facing products99.95%About 22 minutesImportant revenue paths99.99%About 4 minutesCritical systems, with significant cost

Decision factors: how reliable should each service be?

Not every service deserves the same target. Five questions settle most decisions, and the answers usually differ between a checkout flow and an internal report.

Decision factorThe question to askPoints to a higher target whenPoints to a lower target whenCost of failureWhat does an hour of this service being down cost in revenue, penalties or reputation?Revenue or contracts depend on it directlyUsers can wait or retry laterUser toleranceWhat failure rate do users actually notice and complain about?Failures interrupt a task users can’t repeat, such as a paymentUsers retry without noticing, or the work runs in the backgroundDependenciesHow reliable are the services and providers it relies on?You control or duplicate the critical dependenciesIt depends on systems with lower reliability than the targetCost of the next nineWhat redundancy, people and slower releases would a higher target require?The cost is small compared with the cost of failureThe cost is larger than the risk it removesContractsWhat has been promised to customers in SLAs?An SLA requires it, with a margin aboveThere is no external commitment

Dependencies set a ceiling that is easy to miss. If a request needs three services that each manage 99.9%, and they fail independently, the request can succeed at best about 99.7% of the time. A 99.99% target on top of them is not achievable without removing or duplicating those dependencies, and that is where most of the cost of extra nines comes from.

How error budgets balance speed and stability

If your SLO is 99.9%, your error budget is the remaining 0.1%. While the service is within budget, teams can release freely and run experiments. When incidents consume the budget, the agreed response kicks in: slow releases, prioritise reliability fixes and improve testing until the service recovers. Product and engineering agree the rule in advance, so nobody argues about it during an incident.

This links directly to delivery metrics: services that burn budget often usually show a high change fail rate, which DORA metrics make visible.

Error budgets in numbers

An error budget is easiest to agree when it is counted in the units your service handles. For a service that handles 10 million requests a month, a 99.9% SLO allows 10,000 failed or too-slow requests in that month. At 99.95% the allowance halves to 5,000; at 99.99% it is 1,000. Showing the budget this way turns “three nines or four?” into a concrete question: is it worth the extra engineering to fail 9,000 fewer requests a month?

SLOError budgetFailed requests allowed per 10 millionDowntime allowed per 30 days99%1%100,000About 7 hours 12 minutes99.9%0.1%10,000About 43 minutes99.95%0.05%5,000About 22 minutes99.99%0.01%1,000About 4 minutes

An error budget policy leaders can sign

The error budget only works if everyone agrees in advance what happens when it runs out. Google’s example policy is a useful template. If a service has used more than its error budget over the previous four weeks, all changes and releases stop except urgent fixes and security patches, until the service is back within its SLO. If a single incident uses more than 20% of the four-week budget, the team must hold a postmortem with at least one top-priority action to fix the root cause.

The policy also sets exceptions, so teams are not punished for problems outside their control, such as a company-wide network outage, or budget used by load tests. Where people disagree about the numbers or the response, the decision goes to a named executive, in Google’s example the CTO. Writing this down before an incident is what lets the budget settle arguments instead of starting them.

How to choose good SLIs

• Measure what users experience, such as successful requests and response times on key journeys, not server CPU.
• Keep it to a few: two or three SLIs per service are easier to understand and act on.
• Measure close to the user, at the load balancer or from synthetic checks, not only inside the application.
• Define them precisely: which requests count, what “success” means and over what window.

Google’s SRE workbook recommends expressing each SLI as a ratio: good events divided by total events, so every SLI reads as a percentage from 0 to 100. The right SLIs depend on what kind of service it is.

Reliability metrics to report to leadership

Leaders don’t need dashboards full of graphs. A monthly view of five numbers per critical service is enough to see whether reliability is under control and whether money is going to the right places.

• **SLO attainment: **did the service meet its target over the period, yes or no, and by how much.
• **Error budget remaining: **the share of the period’s budget still unused. Low and falling means slow down; high and stable may mean the target is too strict, or you could ship faster.
• **Biggest budget consumers: **the two or three incidents or causes that used the most budget, each with an owner and a fix.
• **Change fail rate: **the share of deployments that needed immediate intervention, from your DORA metrics. It shows whether releases are what burns the budget.
• **Cost of reliability: **what you spend on redundancy, on-call and reliability work for the service, so the target can be weighed against its price.

Start with one service

SLOs work best on top of solid observability and automated operations, part of the shift from migration to cloud maturity. They also give incident reviews a clear measure of impact, which our cyber resilience guide builds on.

Questions to ask your engineering leaders

Do we know how reliable is reliable enough?

• Which of our services have SLOs, and are they based on what users experience?
• How much error budget did our most important service use last month?
• What is our agreed policy when a service runs out of error budget?
• Are our internal SLOs stricter than the SLAs in customer contracts?
• Where are we spending money on reliability that users do not need?

Cloud & DevOps

Want reliability targets everyone agrees on?

We help you define user-focused SLIs and SLOs, agree error budget policies with product and set up the dashboards that make reliability decisions straightforward.

Book a free 30-minute call

Sources

• Service Level Objectives (Google Site Reliability Engineering book)
• DORA software delivery performance metrics (dora.dev)
• Implementing SLOs (Google SRE workbook)
• Alerting on SLOs (Google SRE workbook)
• Example error budget policy (Google SRE workbook)

Originally published at phpscientist.com.