Error Budget Calculator (SRE)
Turn an availability SLO into an error budget: how many downtime minutes you may “spend” per year or period — and how much remains before a release freeze.
Results
Enter data and click Calculate.
What an error budget is
An error budget is a concept from "Site Reliability Engineering" (the Google SRE book) — it is the allowed amount of unavailability implied by a given SLO. If the SLO is 99.9% availability, the error budget is the remaining 0.1% of time the system may be unavailable without breaking the promise made to users.
The formula
Budget = total minutes in the period × (100 − SLO%) / 100. For a year (525,600 minutes) that is 525600 × (100 − SLO) / 100. The calculator computes this automatically for a year, and if you supply any period in days, for that period too, subtracting any downtime already used if you provide it.
SLO and allowed downtime
| SLO | Downtime / year | Downtime / month (30 days) |
|---|---|---|
| 99% | ~3.65 days | ~7.2 hours |
| 99.9% | ~8.76 hours | ~43.2 minutes |
| 99.95% | ~4.38 hours | ~21.6 minutes |
| 99.99% | ~52.6 minutes | ~4.32 minutes |
| 99.999% | ~5.26 minutes | ~0.43 minutes |
MTTR and MTBF help interpret these downtime minutes in terms of incident cadence and repair speed; see the MTTR/MTBF calculator.
How teams "spend" the error budget
- An error budget is not just a number to report — it is a signal for how much risk a team can afford to take. A team with plenty of remaining budget can ship faster and experiment, e.g. testing new features in production.
- When the budget runs out, the standard SRE practice is a feature-release freeze, redirecting effort to stability until the budget rebuilds in the next window.
- It is a tool for the conversation between product teams (who want to ship faster) and operations teams (who want stability) — a concrete number of minutes instead of a subjective "is it stable enough" debate.
Rolling vs calendar windows
A budget can be tracked over a calendar window (month, quarter) or a rolling window (e.g. the last 30 days from today). A rolling window better reflects the service’s current state — it does not artificially "reset" on the first of the month — but requires slightly more monitoring complexity. This calculator computes a budget for the number of days you supply; whether that represents a calendar or rolling window depends on how you measure downtime used.
Examples
- SLO 99.9% → yearly budget of about 525.6 minutes (~8.76 hours) of allowed downtime.
- SLO 99.9%, 30-day period, 10 minutes already used → period budget about 43.2 minutes, about 33.2 minutes remaining.
- SLO 99.99%, 30-day period → period budget about 4.32 minutes — very little tolerance for downtime.
FAQ — error budget
- How is an error budget different from an SLA?
- An SLA (Service Level Agreement) is an external, often contractual promise with financial consequences. An error budget is an internal operational tool based on an SLO, used to decide how fast to ship.
- What happens when the error budget runs out?
- The typical practice is a temporary freeze on new feature releases, redirecting resources toward stability until the budget rebuilds in the next period.
- Is the budget tracked for one SLI or several at once?
- Usually for one key indicator (e.g. HTTP 200 availability) at a time. Systems with multiple SLOs (availability, latency, data correctness) typically track a separate budget for each.
- Is a 100% SLO realistic?
- Practically never — 100% means a zero error budget, which rules out any deployments, maintenance, or even minor network blips. Google SRE recommends setting SLOs lower than what is technically achievable.
- How is "downtime used" measured in practice?
- Usually from a monitoring system (uptime checks, error rate metrics) or an incident log — the duration of every incident affecting the SLI is summed over the period.
- Do short SLO windows (e.g. weekly) make sense?
- Yes — shorter windows give faster feedback but are "jumpier" (a single incident can exhaust the whole budget). Longer windows (a quarter) are steadier but signal problems more slowly.
- Who came up with the error budget concept?
- It comes from the "Site Reliability Engineering" book published by Google in 2016, describing the practices of Google’s SRE team.
- Does an error budget replace monitoring and alerting?
- No — it is a decision metric (e.g. freeze risky deploys when the budget is gone), not a monitoring substitute. Alerts still detect incidents in real time.