# Error Budget Calculator

- **URL:** https://codeasystem.com/calculators/developer/error-budget-calculator/
- **Category:** developer
- **Description:** Track how much of your SLO-derived error budget remains after recorded downtime, with a healthy-or-breached status.
- **Primary output:** Remaining error budget: 33.2 minutes

## Inputs
- SLO availability (name: `slo`, type: number, example: 99.9)
- Rolling window (name: `windowDays`, type: number, example: 30)
- Downtime so far (name: `downtimeMinutes`, type: number, example: 10)

## Outputs
- Remaining error budget: 33.2 minutes
- Total budget for window: 43.2 minutes
- Budget consumed: 10 minutes
- Budget burned: 23.1%
- Status: budget healthy

## Formula / methodology
```
budget = (1 − SLO) × window_days × 1440
remaining = budget − used   burn = used ÷ budget
```

The error budget is the unreliability your SLO tolerates: the complement of availability spread across the rolling window in minutes. Subtracting consumed downtime yields what is left; crossing zero means every further failure breaks the SLO until the window rolls forward.

## Assumptions & limitations
- Google SRE Workbook definition of error budget.
- Downtime measured in wall-clock minutes within the window.
- Window assumed 30 days unless overridden.

## How to use
1. **Set the SLO and window**; Match whatever your organization committed to; commonly 99.9% over 28 or 30 days.
2. **Log accumulated downtime**; Sum incident minutes from monitoring; include partial degradations if your policy says so.
3. **Act on the status row**; Healthy budgets buy feature velocity; breached budgets should freeze risky releases until reliability recovers.

## Example
At 99.9% over 30 days the total budget is 43.2 minutes. Ten minutes of incidents leaves 33.2 minutes; about 23% burned, status healthy.

Result for these inputs:

```
Remaining error budget: 33.2 minutes
```

## About this calculator
### Why budgets beat binary up/down thinking

A hard 100%-uptime goal makes every blip a crisis and discourages deployment. An explicit budget quantifies acceptable failure, letting teams trade release speed against reliability deliberately instead of politically.

### When the budget empties

Standard practice: pause non-critical launches, prioritize reliability work, and add page-level alerts on budget burn rate. The budget refills automatically as the old window slides away; recovery is built into the math.

## FAQs
### What if my downtime already exceeds the budget?

Remaining goes negative and status flips to breached; the honest signal that SLO commitments are currently unmet.

### Should failed requests or minutes count?

Either works; request-weighted budgets are fairer at scale. Keep units consistent between budget and observed errors.

### Who owns the budget?

Typically the service team, with product deciding how to spend velocity and SRE arbitrating when burn accelerates.

## Related calculators
- [Uptime SLA Calculator](https://codeasystem.com/calculators/developer/uptime-sla-calculator/)
- [SRE Burn Rate Calculator](https://codeasystem.com/calculators/developer/sre-burn-rate-calculator/)
- [Runway & Burn Rate Calculator](https://codeasystem.com/calculators/business/runway-burn-rate-calculator/)

---
Last updated: 2026-08-23 · Version: 1.0.0 · [HTML version](https://codeasystem.com/calculators/developer/error-budget-calculator/)