SLO & Error Budget Calculator

How the numbers are derived

Four formulas, all of them arithmetic:

error budget (fraction)  = 1 − (SLO ÷ 100)
allowed downtime         = error budget × window duration
allowed bad requests     = error budget × total requests in window
burn rate                = (bad requests ÷ total requests) ÷ error budget
                           ÷ (fraction of window elapsed)

Nothing is estimated and nothing is fitted. If a figure surprises you, the SLO surprised you.

Downtime allowance by target

The table people actually come for. Read the row, then ask whether your on-call rotation can credibly detect and fix an incident inside that budget — because if it cannot, the SLO is aspirational.

Two things fall out of this table immediately.

Below 99.9%, humans can be in the loop. Seven hours a month is enough to page someone, have them wake up, read a dashboard, and act. At 99.99% they cannot. Four minutes a month means detection and mitigation must both be automatic; a human who responds in three minutes has already spent three quarters of the monthly budget on one incident.

Every nine costs roughly an order of magnitude. Not in downtime — in engineering. The jump from 99.9% to 99.99% typically means multi-AZ, automated failover, load shedding, and a serious investment in observability. Ask what the extra nine is for before buying it.

Why request-based budgets beat minutes

A time-based budget silently assumes traffic is uniform across the window. It never is.

Consider a 30-day window and a five-minute total outage. Time-based, that is 11.6% of a 99.9% budget, regardless of when it happened. Request-based, a five-minute outage at your traffic peak might cost 4% of daily requests, and the same outage at 3am might cost 0.05%. Those are not the same incident, and a budget that cannot tell them apart will let you burn real user-facing reliability while the dashboard stays green.

Use minutes only when you have no per-request telemetry — and treat the answer as a worst case, not a measurement.

The burn-rate bands

Burn rate is what makes an SLO alertable. A raw error-rate threshold either pages you for noise or misses a slow bleed; burn rate normalises for both.

The reason to run two windows per band — a long one for significance and a short one to confirm the problem is still happening — is that a single long window keeps alerting long after an incident has resolved, and a single short window fires on every blip. Google's workbook has the full multi-window configuration; the calculator above gives you the single-window burn rate that those alerts are built on.

The part nobody implements

An error budget with no policy attached is a dashboard. The mechanism only works if exhausting the budget causes something specific to happen — feature freeze, reliability work takes priority, releases require an explicit exception. Write that down before you publish the SLO, get whoever owns the roadmap to agree to it in advance, and make the consequence automatic rather than a negotiation held under pressure during an incident.

The most common failure I see is not a badly chosen SLO. It is a well-chosen SLO that nothing is attached to, quietly breached for two quarters, with everyone still shipping features.

Choosing the target

Do not start from a number of nines. Start from these three questions:

1. What do users actually notice? If they cannot distinguish 99.9% from 99.99% because their own network is worse than both, you are buying reliability nobody consumes.
2. What do your dependencies give you? Your availability cannot exceed the product of everything on your critical path. Three sequential dependencies at 99.9% each cap you at 99.7% before you write a line of code.
3. What would you stop doing to fund it? An extra nine is paid for in engineering time. If nothing comes off the roadmap, the nine is not real.

Then pick the lowest target your users cannot tell apart from perfect, and spend the difference on shipping.