---
title: Can we still ship this week? Check with the Error Budget Calculator
description: Two incidents have used 31 minutes of downtime twelve days into the month, and a risky migration is planned for Friday. With a 99.9% SLO over 30 days the error budget is 43 minutes 12 seconds; 72% is gone and the burn rate is 1.79×, so at this pace it runs out on day 17. Here's how to calculate an error budget and burn rate with the free Error Budget Calculator, and what to decide from the numbers.
canonical: https://watchfor.io/blog/how-to-calculate-an-error-budget
---

# Can we still ship this week? Check with the Error Budget Calculator

2026-10-04 · WatchFor Team · Guides · guides, sre, sla

Two incidents have used 31 minutes of downtime twelve days into the month, and a risky migration is planned for Friday. With a 99.9% SLO over 30 days the error budget is 43 minutes 12 seconds; 72% is gone and the burn rate is 1.79×, so at this pace it runs out on day 17. Here's how to calculate an error budget and burn rate with the free Error Budget Calculator, and what to decide from the numbers.

To calculate an error budget, take the part of the window your SLO allows
to fail: budget = (100% − SLO) × window. A 99.9% SLO over 30 days gives
0.1% × 43,200 minutes = 43 minutes 12 seconds. The burn rate is how fast
you're spending it: the share of budget used divided by the share of the
window elapsed. Above 1×, you'll run out before the window ends.

The free [Error Budget Calculator](/error-budget-calculator) takes an SLO,
a window, the downtime so far and the days elapsed, and returns the budget,
what's left, the burn rate and the day the budget runs out at the current
pace.

## What this tool answers

*How much unreliability do we have left this window, and are we spending it
too fast?* Reach for it after an incident, before a risky release or
migration, in a weekly reliability review, or when deciding whether a
burn-rate alert is worth acting on today.

## A real example

### Calculating an error budget mid-month before a risky change

The situation: a team runs an API with a **99.9% availability SLO over a
rolling 30 days**. Twelve days in, it has had two incidents: a bad deploy
(18 minutes) and a certificate problem at a dependency (13 minutes). Friday
holds a database migration that has caused a few minutes of errors before.
Should it go ahead?

In the [Error Budget Calculator](/error-budget-calculator) we entered SLO
**99.9**, window **30 days**, downtime **31 minutes**, **12 days** into the
window:

![The Error Budget Calculator with a 99.9% SLO over 30 days, 31 minutes of downtime and 12 days into the window: budget consumed 71.8% with a Burning too fast badge, total budget 43m 12s, remaining 12m 12s, burn rate 1.79× and at this pace empty on day 17](/blog/how-to-calculate-an-error-budget-result.webp)

| Card | Value | How it's calculated |
| --- | --- | --- |
| Total budget · 30d | 43m 12s | 0.1% × 43,200 min = 43.2 min |
| Budget consumed | 71.8% | 31 ÷ 43.2 |
| Remaining | 12m 12s | 43.2 − 31 = 12.2 min |
| Burn rate | 1.79× | 71.8% used ÷ 40% of the window elapsed (12 of 30 days) |
| At this pace | Empty on day 17 | 30 ÷ 1.79 = 16.7, rounded up |

The badge says **Burning too fast** because the burn rate is above 1×. The
progress bar is still green, since it only turns amber at 75% consumed:
the bar shows how much is gone, the badge shows the trend.

**The answer:** 12 minutes 12 seconds is left for 18 more days. A
migration with a history of "a few minutes of errors" could use half of
that in one go, and any third incident would take the service past its
SLO. A typical error-budget policy says: postpone the risky change, or make
it safer first (rehearse it, do it in steps that can be rolled back, run it
in the quietest hour). Then spend the remaining days on what caused the two
incidents.

The calculation also shows what "on budget" looks like. On day 12 a
sustainable pace would have used 40% of 43.2 minutes, about 17 minutes. The
team had used 31.

## How to read the results

| What you see | What it means |
| --- | --- |
| **SLO target (%)** | Your objective for the window, with presets from 99 to 99.999. Must be above 0 and below 100. |
| **Window** | 7, 28, 30, 90 or 365 days. The budget scales with it. |
| **Downtime so far (minutes)** | Bad minutes already spent in this window. For a request-based SLO, convert your error ratio to equivalent minutes. |
| **Days into the window** | How far through the window you are. The burn rate needs it; with 0 it shows "—". |
| **Budget consumed + bar** | Share of the budget used. Bar green below 75%, amber from 75%, red at 100%. |
| **Badge** | **Healthy** (burn rate 1× or less), **Burning too fast** (above 1×), **Budget exhausted** (100% or more used). |
| **Total budget · Nd** | Allowed bad time for the whole window. |
| **Remaining / Over budget by** | What's left, or by how much you've gone past it (shown in red). |
| **Burn rate** | 1× spends exactly the budget by the end of the window; 2× spends it by the halfway point. |
| **At this pace** | The day the budget hits zero if the burn rate stays the same, or "Budget holds". |

Below the calculator, the page lists the Google SRE workbook's multi-window
burn-rate alerts for a 30-day SLO: page at **14.4× over 1 hour** (2% of
the budget gone in that hour) or **6× over 6 hours** (5%), open a ticket at
**3× over 1 day** or **1× over 3 days** (10% each).

## More ways to use it

- **After an incident.** Enter the new total and see whether the month is
  still recoverable or the remaining weeks need a change freeze.
- **Choosing an SLO.** Compare windows and targets: 99.95% over 28 days is
  20m 10s; 99.9% over 90 days is 2h 9m 36s, which absorbs one bad day
  better.
- **Sanity-checking an alert.** A page that says "burn rate 14.4×" means at
  that pace the 30-day budget lasts about two days.
- **Explaining reliability to product.** "We've used 72% of the month's
  budget in 40% of the month" is a clearer argument for a release pause than
  "there were two incidents".

## Tips and gotchas

- **An error budget is a policy, not a number.** It only changes behaviour
  if everyone agreed beforehand what happens when it runs low: freeze
  launches, shift people to reliability work, or both.
  [Error budgets explained](/blog/error-budgets-explained) covers writing
  that policy.
- **Rolling windows don't reset on the 1st.** With a rolling 30 days, the
  18-minute incident keeps counting until it's 30 days old. A calendar
  month resets, which is why SLAs prefer it and SRE teams usually don't.
- **The projection is linear.** "Empty on day 17" assumes the first twelve
  days repeat. Incidents come in bursts; read the date as a warning, not a
  forecast.
- **Count what users felt.** Minutes inside announced maintenance are
  usually excluded; minutes when 30% of requests failed may count fully or
  partly, depending on how your SLI is defined.
- **SLO ≠ SLA.** The SLO is your internal target and should be stricter
  than any SLA you've signed, so you hit the alarm before the contract. See
  [SLA, SLO and SLI](/blog/sla-slo-sli).

## Check it from the command line too

The four numbers in one `awk` line, for the same inputs:

```bash
awk 'BEGIN{slo=99.9; win=30; used=31; day=12; b=(100-slo)/100*win*1440; r=(used/b)/(day/win); printf "budget %.1f min, used %.1f%%, left %.1f min, burn %.2fx, empty on day %.1f\n", b, used/b*100, b-used, r, win/r}'
```

```text
budget 43.2 min, used 71.8%, left 12.2 min, burn 1.79x, empty on day 16.7
```

Day 16.7 is what the calculator rounds up to "day 17". Change `slo`, `win`,
`used` and `day` to check your own window.

## Keep watching it

The input that matters most is "downtime so far", and it should come from
measurement, not memory. A WatchFor [HTTP monitor](/http-monitoring) checks
your service from several locations, opens an incident only after a failure
is re-checked from other locations, and counts downtime from confirmed
critical incidents, leaving scheduled maintenance out. Each monitor's
**Uptime SLA** tab breaks that down by day, week or month, and weekly and
monthly reports show total downtime per period, which is the number to type
into the calculator. [How to calculate SLA downtime](/blog/how-to-calculate-sla-downtime)
covers the contract side.

## FAQ

**How do you calculate an error budget?**
Error budget = (100% − SLO) × window length. For 99.9% over 30 days:
0.001 × 43,200 minutes = 43.2 minutes, or 43 minutes 12 seconds.

**What is a burn rate in SRE?**
How fast the error budget is being used compared with a pace that would
spend it exactly by the end of the window. 1× is on track, 2× runs out
halfway through, 14.4× empties a 30-day budget in about two days.

**What happens when the error budget is exhausted?**
Whatever your error-budget policy says. Commonly: feature releases pause
and engineering effort moves to reliability work until the budget recovers
as old incidents age out of the window.

---

Canonical page: https://watchfor.io/blog/how-to-calculate-an-error-budget · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt