How to calculate an error budget and read its burn rate

“We still have budget,” someone says in a hypothetical release meeting. The release includes a data migration, and the team is still working out how to recover if it goes wrong. The budget can tell them how much failure the service has recorded against its target. They still need to answer the recovery question.

Start with the units. If the service targets 99.9% success and saw a million eligible requests, its error budget allows 1,000 bad requests in that window. If 600 were bad, 400 remain. That is a balance for the measured outcome and window.

Calculate the balance in the units you measure

The service level indicator (SLI) is the measure, such as the share of eligible requests that succeeded. The service level objective (SLO) gives that measure a target and a window. Write down which events are eligible and what makes one bad before counting.

For an SLO based on the share of good events, subtract the target from one to get the allowed bad fraction. In the example, 1 − 0.999 = 0.001, or 0.1%. Multiply by one million eligible requests for an allowance of 1,000. Subtract 600 to get 400 remaining. The service has used 60% of its allowance.

Remaining budget is a count in a defined window

Read diagram description

At 99.9% success, one million eligible requests allow 1,000 bad ones. Subtract 600 to get 400 remaining in that window.

For an objective measured in minutes, start with minutes instead. Exactly 30 days contain 43,200 minutes. If 0.1% can be classified as bad, the allowance is 43.2 minutes under that indicator. The request budget does not convert to this duration: a minute at peak load can contain far more requests than a quiet minute. The allowance for one user outcome also does not cover a miss on a separate objective.

Show the SLI, window and calculation time beside the balance. In a rolling window, old failures can age out and improve the number even when nothing was repaired. If the collector lost outcomes for some of the eligible requests, show which observations are missing and follow your missing-telemetry policy. The measurement completeness lab explains why no observation is different from an observed zero.

Use burn rate to compare error fractions

Divide the observed bad fraction by the allowed bad fraction. An hour with 1% errors against a 0.1% allowance has a 10× burn rate. The observed error fraction is ten times the fraction allowed by the objective. Read that rate with its time window, request volume and whether the pattern persists. Google’s guide to alerting on SLOs shows how to compare several windows.

Take two hours from the same completed window, with its 1,000-failure allowance. One hour has 100 bad requests out of 10,000; the other has 10 out of 1,000. Both have 1% errors and 10× burn. The first used 10% of the window’s allowance. The second used 1%. To forecast when the budget will run out, you would also need assumptions about future traffic and error fractions.

Use the policy to make the release decision

The release policy says what high consumption or exhaustion changes about releases and reliability work. It can give a repair that restores service a different path from an unrelated feature. The error budget policy guide develops that distinction, and the calculation template helps put the arithmetic beside the policy.

In the migration meeting, bring two answers: what the measured balance allows under policy, and whether the data can be recovered if the migration goes wrong. The second answer comes from checking compatibility and recovery with the owner who can accept that risk. Put the budget’s indicator, window, calculation time and policy consequence beside the balance so the team can use it for the question it actually answers.