SLO & Error Budget Calculator
Measure your SLI against an SLO target, see the error budget in % and events, and the downtime it allows.
Formula last reviewed 4 August 2026 · How we verify our calculators
SLI meets target ✓
- Target SLO
- 99.9%
- Error budget
- 0.1%
- Allowed failures (budget)
- 3,000
- Failures so far
- 3,000
- Failures remaining in budget
- 0
- Allowed downtime / 30 days
- 43m
Updates live as you type
Frequently asked questions
An SLI (Service Level Indicator) is the measurement — e.g. the percentage of successful requests. An SLO (Service Level Objective) is the internal target for that SLI. An SLA (Service Level Agreement) is a contract with a customer that carries financial or legal consequences if breached.
Teams deliberately keep SLA < SLO < typical performance. The SLO breaches first as an internal early warning, giving you time to react before the contractual SLA — and its penalties — is ever at risk.
It is simply 100% − SLO. A 99.9% SLO leaves a 0.1% error budget — the amount of failure you can “spend” on releases, experiments and incidents before you must stop and focus on reliability.
SLI = successful events ÷ total events × 100. The default example (2,997,000 of 3,000,000) gives exactly 99.9%, matching a 99.9% SLO with a 3,000-event error budget.
For availability SLIs it is convention to count HTTP 2xx and 3xx responses as successful, and 4xx/5xx (or a defined subset) as failures. Define this precisely for your service before measuring.
Right at the edge of compliance, not comfortably inside it
2,997,000 successful out of 3,000,000 total requests, against a 99.9% target SLO, over a 30-day period: the current SLI is 2,997,000 ÷ 3,000,000 × 100 = exactly 99.9% — 3,000 failed events. Because the SLI lands exactly on the target rather than above it, the service sits right at the edge of compliance, not with comfortable room to spare. The error budget itself is 100 − 99.9 = 0.1%, translating to about 43 minutes of allowed downtime over the 30-day period — the same figure the standalone SLA and downtime calculators would produce for an identical 99.9% target over 30 days, since every one of these tools shares the same underlying SLO-to-downtime relationship.
Three terms that get conflated constantly, defined precisely
An SLI (Service Level Indicator) is the measurement of how a service is actually doing — most commonly the share of successful requests. An SLO (Service Level Objective) is the internal target held for that SLI. An SLA (Service Level Agreement) is a contract with a customer that carries financial or legal consequences when missed. SLI is the number, SLO is the goal, SLA is the promise — three distinct things routinely used interchangeably in casual conversation, to the detriment of anyone trying to reason precisely about reliability.
Why the SLA is deliberately looser than the SLO
Keep SLA < SLO < typical performance is the deliberate practice worth internalizing. The SLO is set tighter than the SLA specifically so it breaches first, acting as an early-warning buffer — by the time the contractual SLA is actually at risk, there's already been room to respond. The error budget operationalises this directly: it's the failure allowed to be "spent" on shipping features and running experiments before reliability work has to take priority over everything else.
The defaults reproduce a recognisable reference from the Google SRE workbook — 3,000,000 requests at a 99.9% SLO yielding a 3,000-error budget — so this page demonstrates a known-correct calculation on first load, before substituting a service's real request and success counts.
Sources
- Google SRE Workbook — SLI/SLO/error budget worked example (99.9% SLO, 3,000,000 requests)