SLOs, SLIs, and Error Budgets Explained: The Math Behind Real On-Call Decisions

Quick Answer

An SLO is a specific reliability target you promise internally, like 99.9% of requests succeeding over 30 days. The error budget is simply 100% minus that target, converted into actual allowed minutes of failure, and it is the real number teams use to decide whether it is safe to ship a risky change this week or whether they need to stop and fix reliability first.

SLI, SLO, SLA: Three Letters People Mix Up Constantly

These three terms get used almost interchangeably in casual conversation, but they mean specifically different things, and the difference matters once you are the person on call.

An SLI (Service Level Indicator) is a measurement: a concrete number you can actually calculate from real data, like “the percentage of HTTP requests to the checkout endpoint that returned a 2xx status code in the last 5 minutes” or “the percentage of requests that completed in under 300 milliseconds.” An SLI is not a target, it is just a number that moves over time.

An SLO (Service Level Objective) is the target you set for an SLI: “99.9% of checkout requests will succeed, measured over a rolling 30-day window.” This is an internal commitment, something an engineering team chooses and holds itself to, usually with no contract or money attached to missing it.

An SLA (Service Level Agreement) is a contractual promise made to a customer, usually with real consequences (service credits, refunds, penalty clauses) if it is missed. Critically, a sensible SLA target is almost always set looser than the internal SLO, for example promising customers 99.5% while internally targeting 99.9%, so that the team has room to notice and react to a problem before it becomes a contract violation, rather than the SLA and the SLO being the exact same number.

A concrete way to see all three side by side: the SLI might read “99.87% of requests succeeded in the last 24 hours.” The SLO says that number should stay at or above 99.9% over a rolling 30-day window, so a single bad day reading 99.87% is not automatically a crisis, it depends on how the rest of the month looked. The SLA might promise the customer 99.5% over the same window, with a service credit owed if it is missed. Three numbers, three different jobs: one is a live measurement, one is an internal bar, one is an external, financially binding promise, and conflating any two of them in a conversation with a team is a common source of confusion during a real incident review.

The practical difference that matters day to day: the SLI is what your dashboards show you right now, the SLO is the line that tells you whether that number is a problem, and the SLA is what happens to the business if you cross a much worse line for too long.

The Error Budget Is Just Subtraction, Turned Into Real Minutes

The error budget is the single most useful idea in this whole framework, and it is almost embarrassingly simple arithmetic once you see it worked out with real numbers instead of abstractly.

If your SLO target is 99.9% success over a 30-day window, your error budget is the remaining 0.1%, expressed as actual allowed downtime or failure for that window. Here is the real calculation, run for real:

slo_target = 0.999
window_minutes = 30 * 24 * 60  # 43,200 minutes in 30 days

allowed_bad_fraction = 1 - slo_target
error_budget_minutes = window_minutes * allowed_bad_fraction

Which printed:

SLO target: 99.9% over 30 days
Total minutes in window: 43,200
Error budget (allowed 'bad' minutes): 43.2 minutes (0.72 hours)

So a 99.9% monthly SLO gives you a real, spendable budget of 43.2 minutes of failure across the entire month. That number is the whole point of the exercise: it turns an abstract percentage into something a team can actually plan around, like a budget in rupees. You can spend it on a risky deploy that goes briefly wrong, on planned maintenance, on an unexpected outage, or save it, exactly like money.

This also makes the cost of each additional “nine” concrete rather than vague. Moving from 99% to 99.9% shrinks your allowed downtime from 432 minutes a month (7.2 hours) down to 43.2 minutes, a tenth as much room for anything to go wrong, for one decimal point of target. Moving to 99.99% shrinks it again to about 4.3 minutes a month, which is an extremely demanding target that most products do not actually need and few teams can reliably hit without specialized, expensive engineering investment.

It is worth sitting with how differently this number communicates compared to the raw percentage. Telling an engineering team “we need 99.9% success” is abstract enough that it is easy to mentally round down to “basically no failures allowed, ever.” Telling the same team “we have 43.2 minutes we are allowed to spend this month, and we have not spent any of it yet” reads as an actual resource, something you can check a balance on, the same way you would check how much of a monthly data plan or budget you have left. That reframing, from an abstract target to a concrete, spendable quantity, is the entire reason this framework got adopted as broadly as it has across real engineering organizations, well beyond the specific numbers in any one example.

Burn Rate: How Fast You Are Spending the Budget

Knowing the total budget is 43.2 minutes a month is not enough on its own; what actually matters during an incident is how fast you are consuming it, which is called burn rate. Here is a real worked example of a single incident against that same 99.9% monthly budget:

incident_duration_minutes = 42  # a 42-minute full outage
incident_bad_fraction = 1.0    # fully down, 100% failure during it

budget_consumed_minutes = incident_duration_minutes * incident_bad_fraction
budget_consumed_pct = (budget_consumed_minutes / error_budget_minutes) * 100

fraction_budget_consumed = budget_consumed_minutes / error_budget_minutes
fraction_window_elapsed = incident_duration_minutes / window_minutes
burn_rate = fraction_budget_consumed / fraction_window_elapsed

Which printed:

Incident: 42-minute full outage
Error budget consumed by this incident: 42.0 minutes
That is 97.2% of the WHOLE month's error budget, in one incident

Burn rate during the incident: 1000.0x

A single 42-minute outage ate 97.2% of the entire month's allowed failure, in one event. The burn rate of 1000x means: at the rate the budget was being consumed during that incident, the team would exhaust an entire 30-day budget in roughly 43 minutes if that rate continued, which it did, almost exactly. A burn rate of 1.0x means you are spending the budget exactly as fast as a sustainable, break-even pace for the window; anything meaningfully above 1.0x means you are on track to blow through the whole budget before the window ends, which is precisely the signal that should page someone.

It is worth contrasting this with a smaller, slower incident to see why the multiplier itself, not just the raw minutes, is the useful signal. A 10-minute partial outage affecting 20% of traffic consumes only 2 minutes of budget (10 minutes multiplied by a 0.2 bad fraction), under 5% of the month's total budget, at a correspondingly low burn rate. The exact same team, looking only at “an incident happened” without the burn-rate math, might treat a 42-minute full outage and a 10-minute partial one as roughly similar severity events. The burn rate calculation makes the real difference explicit and comparable: one event was a minor blip against the monthly budget, the other nearly exhausted it in under an hour, and that distinction is precisely what should drive how urgently each gets treated afterward.

Multi-Window, Multi-Burn-Rate Alerting: The Real Framework Teams Use

Simply alerting whenever burn rate crosses some single threshold has an obvious problem: a short, sharp blip would trigger it just as easily as a real sustained outage, generating noisy pages for things that resolve themselves in seconds. Google's SRE Workbook, the standard reference most real SRE teams build their alerting around, solves this with a pattern called multi-window, multi-burn-rate alerting, which has specific, documented numbers rather than vague guidance.

The standard configuration defines three alert tiers, each requiring both a short window (for recency, confirming the problem is happening right now) and a longer window (for confidence, confirming it is not just a blip) to agree before firing:

The 14.4x number is not arbitrary: it is specifically chosen so that consuming 2% of a 30-day error budget within just 1 hour triggers it, meaning for a 99.9% SLO the actual error-rate threshold works out to 14.4 multiplied by the 0.1% allowed error rate, or about 1.44%. The two fast tiers (14.4x and 6x) are built to catch acute incidents quickly, while the slowest tier, at a 1x burn rate sustained over 3 days, exists specifically to catch a slow, quiet leak, a gradually elevated error rate that never spikes hard enough to page, but would fully drain the month's budget if nobody noticed it in time.

It is worth walking through why a single-window alert fails in a way the two-window design specifically fixes. Imagine only checking the 1-hour window: a brief five-minute network blip that resolves on its own could spike the short-term burn rate briefly, trigger the page, and then clear up by the time anyone looks, training the on-call rotation to distrust and eventually ignore pages. Checking only a long window, like 6 hours, has the opposite problem: it would correctly ignore that five-minute blip, but it would also take a long time to notice a genuinely bad, sudden outage, delaying the page by hours relative to when the problem actually started. Requiring both windows to agree, a short one for “is this happening right now” and a long one for “has this been happening long enough to be real,” is what lets the same alerting system catch a genuine fast-burning incident quickly while still filtering out the blips that would otherwise erode trust in the paging system entirely.

This is the actual mechanism, with the actual numbers, behind the “error budget” idea moving from a nice philosophy into a real, automated paging decision.

Choosing the Right SLO Target (Most Products Do Not Need 99.99%)

Every additional nine of reliability is not a linear increase in difficulty, it is roughly an order of magnitude harder, because the error budget shrinks by about 10x for each nine added: 99% allows 7.2 hours of downtime a month, 99.9% allows 43.2 minutes, 99.99% allows about 4.3 minutes, and 99.999% (true “five nines”) allows roughly 26 seconds a month. Hitting that last tier reliably typically requires redundant infrastructure across multiple geographic regions, extensive automated failover, and a level of operational maturity that is genuinely expensive to build and staff.

Picking a target should start from what users and the business actually need, not from what sounds impressive. A banking core transaction system or a hospital's patient monitoring backend has a real, defensible case for 99.99% or higher. A student project, an internal admin tool, or an early-stage startup's main product very often does not, and chasing 99.99% there mostly means burning engineering time on reliability work that nobody downstream actually needed, instead of shipping features. A deliberately modest SLO, honestly chosen and actually met, is a far more useful signal than an aspirational one that gets quietly ignored the first time it is missed.

A useful question to ask before committing to any target is simply: what would a real user actually notice? Most users cannot tell the difference between a service that is reliable 99.9% of the time and one that is reliable 99.99% of the time, because the difference between 43 minutes and 4 minutes of monthly disruption, spread across normal usage patterns, is rarely something an individual person directly experiences as a pattern. What they absolutely do notice is a service that is reliably below 99%, where outages become a recognizable, recurring annoyance. This is why the right target is usually set by working backward from a specific, named consequence of missing it, lost revenue during a checkout outage, a support ticket spike, a contractual SLA breach, rather than picking a number that simply sounds reassuring in a planning document.

What Actually Happens When the Budget Runs Out

The entire reason error budgets exist as a formal practice, rather than just a vague “try to be reliable” mandate, is that running out of budget is supposed to trigger a real, predefined policy change, not just a bad feeling. In teams that run this well, an exhausted error budget for the current window means: new risky feature launches get paused, the next deploys require extra review or get held back, and the team's priority for that period shifts explicitly toward reliability work, fixing the root causes that burned the budget, rather than shipping new functionality.

This creates a genuinely useful, structural tension between product and reliability priorities, instead of reliability being an afterthought that only gets attention during an active outage. It also protects the team from the opposite failure mode: a service that is far more reliable than its target, with lots of unused error budget, is explicitly a signal that the team can afford to take more risks, ship faster, or run more experiments, because they have margin to spend. An error budget policy without this consequence attached is usually just a number on a dashboard nobody acts on, which is the most common way teams adopt the vocabulary of SLOs without getting any of the real benefit.

A concrete version of this policy in action: a team notices on the fifteenth of the month that an early outage has already consumed 80% of the monthly error budget. Rather than treating this as just a bad month to note in a retrospective, the team explicitly delays a planned risky migration to the following month, adds an extra reviewer to any remaining deploys for the rest of the window, and pulls one engineer off feature work to investigate the root cause of the earlier outage. None of this requires a new incident to justify it, the error budget number itself is the trigger. This is the specific behavior that separates teams who have genuinely adopted error budgets as a working tool from teams who have only adopted the vocabulary.

Common Mistakes Teams Make With SLOs

• Picking a target for how it sounds, not what users need. “99.99% uptime” looks better in a slide deck than 99.9%, but if nobody can tell the difference in practice and hitting it requires serious extra investment, it is a vanity target, not an engineering one.
• Measuring something that is not actually user-facing. A simple health check endpoint that just returns “OK” can stay green while the real checkout flow is completely broken for users. A good SLI measures something a real user would actually notice and care about, not just whether a process is technically alive.
• Having no error budget policy at all. Tracking the number without any agreed consequence for exhausting it turns the whole framework into a dashboard decoration rather than a decision-making tool.
• Using a single-window alert instead of multi-window, multi-burn-rate. A naive single-threshold alert either fires on harmless blips constantly (and gets ignored) or misses slow leaks entirely, which is exactly the problem the Google SRE Workbook's two-window pattern above was designed to solve.

A related and easy mistake worth naming on its own: setting an SLO and then never revisiting it as the product or its usage pattern changes. A target that made sense for a product with a thousand users may be badly miscalibrated once it has a million, either too loose to mean anything or too strict to be realistically maintained given the new scale and failure modes that come with it. Treating the SLO as a one-time setup task rather than something reviewed periodically, alongside real incident history and actual user expectations, is how teams end up with a target that technically exists but has quietly stopped reflecting anything useful about the product it is meant to describe. Reviewing the SLO at least once a quarter, alongside whatever incident history accumulated since the last review, is a cheap habit that keeps the target honest.

Frequently Asked Questions