SLO & Error Budget Calculator

Reliability as a budget rather than a goal

Out of 3,000,000 requests, 2,997,000 succeeded. That is an SLI of 99.9% against an SLO target of 99.9% — exactly on target, with an error budget of 0.1%, or 3,000 allowed failures in the period. All 3,000 have been spent, leaving nothing remaining and about 43 minutes of allowed downtime across the 30-day window.

The reframing that makes SLOs useful is this: reliability is not something you maximise. It is something you budget. A target of 100% is neither achievable nor desirable, because the last fraction of a percent costs more than it is worth and removes all capacity to ship changes.

The three terms, precisely

SLI — Service Level Indicator. What you actually measured. Here, successful requests divided by total requests: 2,997,000 ÷ 3,000,000 = 99.9%.

SLO — Service Level Objective. The internal target you hold yourselves to. A number your team chooses and engineers against.

SLA — Service Level Agreement. The contractual commitment to customers, with financial consequences attached.

The ordering matters and is deliberate: SLA < SLO < 100%. The SLO is set stricter than the SLA so that breaching your internal target is a signal to act, not an event that already costs money. A team running an SLO of 99.9% against an SLA of 99.5% has a genuine margin in which to notice and respond.

The error budget

Error budget = 100% − SLO Allowed failures = total events × error budget

At a 99.9% SLO over 3,000,000 requests, the budget is 0.1% × 3,000,000 = 3,000 failed requests.

That number is the point of the entire exercise, because it converts an abstract reliability target into a quantity you can spend. Budget remaining is permission to take risk: ship the risky migration, run the load test in production, deploy on a Friday. Budget exhausted is a signal to stop feature work and spend the next period on reliability.

Google's SRE practice formalises this as a policy agreed in advance between product and engineering — when the budget is gone, releases pause until it recovers. The value is less in the enforcement than in having the argument once, in calm conditions, rather than repeatedly during incidents.

Choosing the target

Higher is not better. Each nine roughly multiplies the engineering cost while delivering diminishing user-visible benefit, and there is a floor below which users cannot perceive the difference anyway — if the average mobile network drops 1% of connections, a service at 99.99% and one at 99.999% are indistinguishable to the person holding the phone.

Practical guidance: set the SLO just above the threshold where users actually complain, measure for a quarter, and adjust. An SLO nobody has ever breached is set too low to be informative; one breached every month is set too high to be actionable.

What counts as a success

The definition does more work than the arithmetic. Decide explicitly whether to count 4xx responses as failures — a 400 caused by a malformed client request is arguably not your service failing, while a 429 from your own rate limiter arguably is. Decide whether slow-but-successful responses count; many teams define an SLI as "requests served successfully within 300 ms," which captures latency and availability in one measure.

Whatever you choose, write it down. Most disagreements about whether an SLO was met are really disagreements about the definition.

Common mistakes

Setting the SLO equal to the SLA. There is then no margin between an internal warning and a contractual breach.

Targeting 100%. It removes the error budget entirely and with it any capacity to deploy.

Measuring at the wrong point. An SLI measured at the load balancer misses failures that never reached it — DNS, CDN and client-side errors are invisible.

Averaging across endpoints. A healthy bulk endpoint can mask a broken checkout flow. Set SLOs per critical user journey.

Having no policy for exhaustion. An error budget nobody acts on is a metric, not a mechanism.