--- title: Error Budget Calculator & SLO Burn Rate description: Free SRE error budget calculator. Pick an SLO target and window, enter downtime consumed, and see your remaining error budget, burn rate multiplier and projected exhaustion — with Google SRE fast-burn alert thresholds. canonical: https://watchfor.io/error-budget-calculator --- [Back to all free tools](/free-tools) # Error Budget Calculator SRE-grade error budget math — pick an SLO target and window, enter the downtime you've already burned, and see the remaining budget, burn rate multiplier and projected exhaustion date. Includes fast-burn alert thresholds and a nines reference table. Free, instant, no signup. [How to use this tool](/blog/how-to-calculate-an-error-budget) SLO target (%) 99 99.5 99.9 99.95 99.99 99.999 Window Downtime so far (minutes) Days into the window Budget consumed: 23.1 % Healthy Total budget · 30 d 43m 12s Remaining 33m 12s Burn rate 0.69× 1× = exactly on budget for the window At this pace Budget holds ## Fast-burn alert thresholds (Google SRE) The standard multi-window burn-rate policy for a 30-day SLO. Each alert pairs a long window with a short one so pages stop firing once the incident is over: Severity Long window Burn rate Budget consumed Page 1 hour 14.4× 2% of monthly budget Page 6 hours 6× 5% of monthly budget Ticket 1 day 3× 10% of monthly budget Ticket 3 days 1× 10% of monthly budget Pair this calculator with the [uptime calculator](/uptime-calculator) to translate SLO percentages into plain downtime numbers for any period. ## Frequently asked questions What is an error budget? An error budget is the amount of unreliability your SLO allows: budget = 100% − SLO target. A 99.9% SLO over 30 days gives you 0.1% × 30 days ≈ 43 minutes of "allowed" downtime. Instead of treating every minute of downtime as a failure, SRE practice treats the budget as a resource you deliberately spend — on risky deploys, experiments and maintenance — as long as you don't overspend it. What is a burn rate? Burn rate measures how fast you're consuming the budget relative to the sustainable pace. Burn rate 1 means you'd use exactly 100% of the budget by the end of the window; burn rate 10 means you're burning ten times too fast and will exhaust it in a tenth of the window. It's the standard way to make error budgets actionable: you alert on burn rate, not on individual failures. What burn rates should trigger alerts? Google's SRE workbook recommends multi-window burn-rate alerts for a 30-day SLO: page immediately when the 1-hour burn rate exceeds 14.4 (you'd burn 2% of the monthly budget in that hour) or the 6-hour rate exceeds 6; open a ticket when the 24-hour rate exceeds 3 or the 3-day rate exceeds 1. Two windows per alert (a long one plus a short 'still burning' check) prevent alerts from firing long after the incident ended. What's the difference between SLI, SLO and SLA? An SLI (service level indicator) is the measurement itself — e.g. the fraction of successful requests. An SLO (objective) is your internal target for that SLI — e.g. 99.9% over 30 days. An SLA (agreement) is the contractual promise to customers, usually looser than the SLO and with financial penalties attached. The error budget is defined by the SLO; the SLA is what happens when you blow through it badly. Should I use a 28-day or calendar-month window? 28-day rolling windows are generally better: every window contains exactly four weekends, so week-driven traffic patterns don't skew the math, and the window slides smoothly instead of resetting at midnight on the 1st. Calendar months are easier to explain to customers and match billing periods — which is why SLAs use them even when the internal SLO runs on 28 days. What should happen when the error budget is exhausted? The classic SRE policy: freeze risky changes — feature releases stop, and engineering effort shifts to reliability work until the budget recovers. The exact policy matters less than having one agreed in advance; the budget only changes behavior if exhausting it has consequences that product and engineering both signed up to. Why not just aim for 100% uptime? Because your users can't tell the difference and the cost curve is brutal — each extra nine roughly multiplies the engineering cost. A user on flaky Wi-Fi experiences your 99.99% service and a 100% service identically. The error budget formalises this: reliability above the SLO is not a win, it's an unspent budget you could have used to ship faster. How do I measure my actual error budget consumption? You need continuous, external measurement of your SLI — for availability that means uptime checks from multiple regions at short intervals, with multi-location confirmation so a single probe's network blip doesn't count against the budget. Each confirmed-down minute is budget spent; an uptime monitoring service tallies this automatically and shows the running total per month. ## Know your burn rate before it pages you An error budget is only as good as the measurement behind it. WatchFor tracks confirmed downtime from multiple regions, shows monthly SLA reports and alerts you while there's still budget left to save. [Start monitoring for free](/pricing) Free plan · 15 monitors · no credit card required --- Canonical page: https://watchfor.io/error-budget-calculator · Site guide: https://watchfor.io/llms.txt