# Error budgets and burn rate

An error budget is the amount of imperfection your objective allows. This guide explains budget left, burn rate and the charts you see in Service Health, with numbers you can work through.

## How much can go wrong?

Subtract your objective from 100%. A 99% objective allows 1% of calls to be bad. For a speed objective, bad means over the slow line. For a success objective, bad means a server error.

Suppose an API receives 100,000 calls in its window and has a 99% speed target:

| Reading | Calculation | Result |
| --- | --- | --- |
| Allowed slow calls | 100,000 × 1% | 1,000 |
| Actual slow calls | Counted over the slow line | 600 |
| Budget spent | 600 ÷ 1,000 | 60% |
| Budget left | 100% − 60% | 40% |

**40% budget left does not mean 40% of calls succeeded.** In this example 99.4% met the speed threshold. Budget left tells you how much of the allowed imperfection remains.

At 1,000 slow calls the budget is used up. More than that puts the API beyond its allowance; budget left can be negative. These budgets are based on calls, so they are not a fixed number of minutes of downtime.

## What is burn rate?

Burn rate compares the recent share of bad calls with the share the objective allows:

```text
burn rate = recent bad-call percentage / allowed bad-call percentage
```

With a 99% target, the allowance is 1%. A recent bad-call rate of 2% means a burn rate of 2.

- **Below 1:** the recent bad-call share is below the allowance.
- **1:** continuing at this rate spends one full allowance across a whole window.
- **2:** at a steady rate and traffic volume, a fresh budget would last about half a window.

The app's estimate of when the current budget will run out also takes account of what is left. It is a projection from recent traffic, not a deadline or a promise. No recent measurements means there may be no projection.

## Healthy, at risk or breached?

| Status | Meaning for an objective |
| --- | --- |
| Healthy | There is budget left and neither at-risk condition applies |
| At risk | Less than 50% remains, or the recent pace projects exhaustion in less than 7 days |
| Breached | Budget left is zero or negative |

An objective with no usable measurements has no health reading. An API with fewer than 100 calls in its window is not given a health judgement. Missing data is not evidence that it is healthy.

## The budget line

The line starts at 100% and subtracts each day's bad calls against the allowance for the displayed window's total calls. The even-spend line shows a pace that would use the allowance evenly over the window.

A sharp drop tells you when much of the allowance was spent. Open that day to investigate. The chart reconstructs spending within the current window; as the window and total traffic change, it can change too. It is not a bank balance carried forward forever.

## A whole service's budget

A service's speed budget counts its eligible APIs' calls against the service's own target and slow line. **Who spent it** shows each API's share of the slow calls spending that allowance.

This is different from averaging API budgets. A busy API contributes more calls than a quiet one, and an API's override does not change the service's own target. Check individual problem APIs as well: a service-wide aggregate can hide trouble on a quiet endpoint.

## Burn spikes

Burn spikes identify hours spending more than 2% of a 28-day budget, joining adjacent hours that keep spending that quickly. Larger dots represent more budget spent; a spike spending at least a quarter is red. They use the retained five-minute detail, so cover at most the last 14 days and depend on which APIs keep that detail.

Open a spike to reach its service, or its main contributing API when one is identified. Compare the timing with a release, a traffic change or an external dependency problem before deciding what caused it.

## How should a team use the budget?

Agree what to do before it runs out. For example, your team might prioritise reliability work over a risky release when little budget remains. That is a team decision; Service Health does not block deployments.

Avoid making the target easier simply to restore a healthy colour. Check whether it still represents the user experience you intended to protect.

## Learn more

- [Reading the health screens](/docs/service-health/reading-health)
- [Alerts and Jira tickets](/docs/service-health/alerts-and-tickets)
- [Google SRE workbook: Error budget policy](https://sre.google/workbook/error-budget-policy/)