Turn an SLO target and time window into error budget minutes. Add incident downtime to see how much budget you burned.
Sum all qualifying outages in the window.
budget = period_min × (1 − SLO/100)
burn% = used / budget × 100
An error budget is the amount of failure your service can tolerate in a fixed time window and still meet its Service Level Objective (SLO). If your SLO is 99.9% availability over 30 days, the budget is roughly 43.2 minutes of downtime. Spend more than that on qualifying incidents and you miss the objective — even if the outage felt small to customers.
Google popularized error budgets in Site Reliability Engineering. The idea is pragmatic: chasing 100% uptime is expensive and often unnecessary. A defined budget lets product teams ship features while reliability sets guardrails. When burn is high, slow risky releases. When budget remains, you can accept more deployment risk — deliberately, with numbers on the table.
Without a budget, every outage triggers the same emotional debate: “How could this happen?” With a budget, the conversation shifts: “Did we spend our allowance wisely, and what policy should change?” That framing helps product managers and engineers negotiate tradeoffs without pretending outages will never occur.
Error budgets also connect operational metrics to business language. A 20-minute outage on a 99.9% SLO consumes about 46% of a 30-day budget. That single number is easier to put in a weekly review than a wall of charts — especially when paired with dollar impact from our Downtime Cost Calculator.
Period length (minutes) = days × 24 × 60
Error budget (minutes) = period_minutes × (1 − SLO / 100)
Burn % = incident_downtime_minutes / error_budget × 100
Remaining budget = max(0, error_budget − incident_downtime)
This calculator treats “incident downtime” as the sum of minutes you count toward the SLO in your internal policy. Your contract may exclude planned maintenance, partial degradation, or regions outside scope — always align inputs with your SLO document, not with gut feel.
Inputs: SLO 99.9%, period 30 days, one incident of 20 minutes.
Period minutes = 30 × 24 × 60 = 43,200
Budget = 43,200 × (1 − 0.999) = 43,200 × 0.001 = 43.2 minutes
Burn = 20 / 43.2 × 100 ≈ 46.3%
Remaining ≈ 23.2 minutes — you still meet the SLO, but nearly half the budget is gone with weeks left in the period.
Inputs: SLO 99.99%, period 30 days, 5 minutes down.
Budget = 43,200 × 0.0001 = 4.32 minutes
Burn = 5 / 4.32 × 100 ≈ 115.7%
Result: SLO missed. Five minutes feels trivial until the target is four nines — a common surprise for teams upgrading objectives without upgrading architecture.
Inputs: SLO 99.5%, period 90 days. Incidents: 12 min + 8 min + 25 min = 45 minutes total.
Period minutes = 90 × 24 × 60 = 129,600
Budget = 129,600 × 0.005 = 648 minutes (10.8 hours)
Burn = 45 / 648 × 100 ≈ 6.9%
Interpretation: healthy headroom, but log each incident separately in your post-mortem tracker so patterns (same root cause recurring) do not hide inside a low burn percentage.
The math matches our Allowed Downtime Calculator. An SLO is an internal target you control and measure. An SLA is a customer contract — often legally binding with service credits. Error budget is the SRE vocabulary for the same time allowance, used to govern release policy and incident response intensity.
Internal SLOs are frequently stricter than external SLAs so you get warning before a customer-facing breach. Example: SLO 99.95% internally, SLA 99.9% to customers — the gap is your safety margin.
Real SLOs may count failed requests, latency thresholds above p99, or geographic slices separately. Vendor status pages may disagree with your internal probes. Use this calculator for planning, team conversations, and post-incident math — not as the authoritative compliance record.
Advanced SRE setups track burn over multiple windows — for example a fast burn alert on a 1-hour window and a slow burn review on 30 days. This calculator implements the single-window minute budget that underpins those policies. If your observability tool reports “14.4× burn rate,” it is comparing current consumption to what the budget allows per hour/day — not magic, just scaled arithmetic on the same budget formula.
Request-based SLOs (e.g. 99.95% of requests succeed under 300 ms) convert to error budget in failed request count, not minutes. Translate only when you define an equivalence: “We treat any 5-minute window above 1% error rate as downtime for executive reporting.” Document that mapping; do not silently equate minutes and failed requests.
Publish the policy before an incident so product cannot interpret “blameless” as “no guardrails.” Error budget is how SRE teams say no with data instead of politics.
99.9% target, one 30-minute incident
March (31 days, 44,640 min): budget ≈ 44.6 min → miss (30 min would pass, 45 min fails).
Rolling 30 days (43,200 min): budget ≈ 43.2 min → same incident at 30 min passes, at 44 min fails.
Lesson: period definition changes pass/fail near the boundary. Align with customer contract language.
Map SEV definitions to budget impact early. Example: SEV1 customer outage always logs full minutes; SEV3 internal-only degradation logs zero toward customer SLO but still tracks in a separate internal budget. Mixed models confuse teams if not written down — one page in the runbook beats hallway debates.
Executives rarely think in “99.9%.” They think in quarters and revenue. When you present error budget, bring three numbers: minutes used, minutes allowed, and dollars at risk if the next incident hits peak hour. Example script: “We have 23 minutes of budget left this month. Last Tuesday’s event cost 20 minutes and about $14k in checkout revenue. One repeat event exhausts the SLO.” That connects SRE vocabulary to finance without overselling precision.
For product leaders, frame budget as deploy velocity: “We still have 60% budget — safe to ship the pricing experiment.” When budget is gone, offer alternatives: feature flags, dark launch, or delay until next period. Error budget is the negotiated contract between speed and stability — the calculator just makes the contract visible.
Rolling windows help teams that ship continuously. Calendar months help billing-aligned SLAs. If your customer contract says “monthly uptime,” but engineering uses rolling 28-day SLO internally, document both numbers in the post-mortem so customer success does not quote the wrong one to accounts.
SLO dashboards in Grafana or Datadog should display the same period and target you enter here. When leadership asks “are we green?” the answer is budget remaining %, not gut feel about incident count.
| SLO | Budget (min) | ≈ Hours | Typical use |
|---|---|---|---|
| 99% | 432 | 7.2 | Internal tools, batch systems |
| 99.9% | 43.2 | 0.72 | Standard SaaS customer SLA |
| 99.95% | 21.6 | 0.36 | High-trust B2B platforms |
| 99.99% | 4.32 | 0.072 | Payment, critical infra |
These assume 30 × 24 × 60 = 43,200 minutes. Adjust period days in the calculator for your window. Moving from 99.9% to 99.99% cuts budget by ten× — architecture and ops cost usually jump similarly; use Cost of Nines before promising the extra nine.
Burn rate alerts in production often use multiples: “2× burn” means you are consuming budget twice as fast as time elapsing in the window — at that pace you will miss before period end even if current absolute minutes look small. Teaching that concept prevents teams from ignoring early yellow flags.
Dollar impact: Downtime Cost Calculator · Allowed minutes: Allowed Downtime · Investment case: Reliability ROI · Curated path: Reliability Money Toolkit · Full catalog: Free Tools · Reference tables: SLA uptime → downtime reference.
The maximum amount of failure — usually downtime minutes — your service can absorb in a period and still meet its SLO. It is the gap between 100% and your target, expressed as time.
Multiply period length in minutes by (1 − SLO/100). Example: 99.9% over 30 days → 43,200 × 0.001 ≈ 43.2 minutes of budget.
You have consumed the entire error budget for that period. Any additional qualifying downtime means you missed the SLO unless your contract defines partial credit or rolling windows differently.
Match whatever your SLO document says. Customer SLAs often use calendar months; internal SRE teams often prefer rolling 28- or 30-day windows so one bad week does not hide inside a quiet month.
The math is identical when SLO equals uptime percentage. Error budget is the SRE vocabulary; allowed downtime is common in SLA spreadsheets.
No. This tool sums downtime minutes only. Latency SLOs need request-level metrics from your observability platform.
There is no universal rule. Many teams pause risky deploys above 50% burn mid-period or when burn rate spikes. Document your policy so product and engineering agree before an incident.
Error budget answers whether you met a reliability target in minutes. Downtime cost translates the same minutes into dollars. After an incident, run both for the SLO review and the business case.