Error Budgets: What They Are and How to Use One

An error budget is the amount of unreliability your SLO allows over a period: 100% minus the target. A 99.9% SLO over 30 days leaves an error budget of 43 minutes 12 seconds of downtime, or one failed request in every thousand. While budget is left, the team can ship and take risks. When it runs out, reliability work comes first until the window recovers.

That one rule turns a reliability target into decisions. This guide shows how to calculate an error budget, what should and shouldn’t spend it, how to tell how fast you’re spending it, and how to write a policy for when it runs out.

How to calculate an error budget

You need two things: an SLO, the reliability target you set for yourself, and a window, the period it is measured over. The error budget is what is left between the target and perfect.

Error budget = (100% − SLO) × window

For a 99.9% SLO over 30 days (43,200 minutes): 0.1% × 43,200 = 43.2 minutes, which is 43 minutes 12 seconds. The table shows the same math for common targets, rounded down to the second.

SLO	Budget per 30 days	Budget per 90 days
99%	7h 12m	21h 36m
99.5%	3h 36m	10h 48m
99.9%	43m 12s	2h 9m 36s
99.95%	21m 36s	1h 4m 48s
99.99%	4m 19s	12m 57s

The SLA and uptime calculator does this for any target and period. It uses the average month (a year divided by 12), so it shows 43 minutes 49 seconds for 99.9% rather than the 30-day figure above.

Time-based or request-based

An error budget can be counted in two units, depending on the SLI behind your SLO:

• Time-based: minutes of downtime, measured by checks from outside. It is simple, easy to explain and matches how most customer SLAs are written. A 99.9% monthly SLO allows about 43 minutes.
• Request-based: the share of requests that failed, counted from load balancer or application logs. At 2 million requests a month and 99.9%, the budget is 2,000 failed requests. It weighs busy hours more than quiet ones, which is closer to what users feel, but needs logging you trust.

Many teams use both: a time-based budget from external checks for the service as a whole, and request-based budgets for the endpoints that matter most, such as checkout or the API.

Why have an error budget at all

Without a budget, reliability is an argument. Product wants to ship, engineering wants to slow down, and whoever talks last wins. A budget replaces the argument with a number both sides agreed on in advance.

• It makes 100% the wrong goal. A 100% target leaves no budget, so every deploy is a risk nobody may take. Users can’t tell 99.99% from 100% through their own Wi-Fi and mobile networks anyway.
• It makes risk spendable. A big migration, a new region or a risky release can be planned to fit the budget that is left this month.
• It decides priorities for you. When the budget is gone, the policy says what happens next, so nobody has to win a meeting to get reliability work on the roadmap.

What spends the budget

Anything your SLI counts as bad spends budget. Decide this when you write the SLO, not during the incident.

• Confirmed outages: the service didn’t answer, answered with an error, or answered with the wrong content.
• Slow responses, if your SLI says a request slower than a limit counts as failed. A page that takes 30 seconds is up, but not usable.
• Failed deploys and rollbacks, for the minutes users saw errors.
• Outages at your providers. If your payment provider or DNS host fails, your users still can’t check out. It spends your budget even though the fix isn’t yours, which is a good reason to watch the services you depend on.
• Planned maintenance, only if the SLO says so. Many teams exclude announced maintenance windows, with a cap per month.

What should not spend it: false positives. A single failed check from a network blip isn’t downtime. Confirm a failure with a second check before you count it, or your budget drains on problems users never saw.

Burn rate: how fast you’re spending

The budget tells you how much failure you can afford. The burn rate tells you how fast you’re using it. Google’s SRE workbook defines it as how fast, relative to the SLO, the service consumes the error budget (Alerting on SLOs).

• A burn rate of 1 spends the whole budget exactly at the end of the window.
• A burn rate of 2 spends it in half the window: 15 days of a 30-day month.
• A full outage burns at 1,000 against a 99.9% SLO, since every minute down is a thousand times the allowed rate. Twenty minutes of it spends 46% of a 30-day budget.

The workbook’s recommended starting point for a 99.9% SLO pages someone when 2% of a 30-day budget burns within an hour (a burn rate of 14.4) or 5% within six hours (a burn rate of 6), and opens a ticket when 10% burns within three days (a burn rate of 1). Each alert also checks a short window, so it stops firing soon after the problem does.

For a hard outage, a burn-rate alert and an ordinary “site is down” alert fire at about the same moment. Burn rates earn their keep on partial failures: 3% of requests failing for hours, which never takes the site down but quietly spends the month’s budget by Wednesday.

Write an error budget policy

A budget without a policy is just a number on a dashboard. The policy says, in advance, what the team does at each level of spend. Agree on it with product and engineering together, and write it down where both can find it. Google publishes an example error budget policy worth reading before you write your own.

A simple policy to start from

1. Budget left: ship as normal. Planned risky work goes ahead.
2. Half spent before mid-window: the on-call lead reviews the incidents so far and names the biggest cause.
3. Budget spent: only bug fixes and reliability work ship until the window recovers. Risky migrations wait.
4. A single incident spent more than a fifth of the budget: it gets a written postmortem with at least one action item.
5. Exceptions are decided by named people, such as the head of engineering and the head of product together, and written down.

The thresholds are examples, not rules. Pick ones your team will actually honor. A policy that is ignored the first time it bites is worse than none, because it teaches everyone that the SLO doesn’t matter.

Common mistakes

• Setting the SLO equal to the SLA. Then the budget runs out at the same moment you owe customers service credits. Keep the SLO tighter than the SLA, so the internal alarm rings first. SLA vs SLO vs SLI explains how the three fit together.
• A window that is too short. A weekly budget resets before a bad week can change anything. Thirty days, rolling or per calendar month, is the usual choice.
• Forgetting how the window resets. A calendar month starts fresh on the 1st, so a bad last week is forgotten in days. A rolling 30-day window remembers it for a month, which is stricter and fairer.
• Looking only at the total. One 40-minute outage and forty 1-minute outages spend the same budget, but the second breaks users’ work every day. Track the number of incidents and MTTR next to the budget.
• Measuring only from inside. Server logs can’t record requests that never arrived. An expired certificate or a broken DNS record spends budget that only an external check sees.

Tracking a time-based error budget with Uptimecheck

Uptimecheck gives you the numbers a time-based budget needs. Uptime monitoring checks every minute from Stockholm, Sweden, and confirms each failed check with a second one about 10 seconds later, so a single blip doesn’t spend budget. Maintenance windows and paused time don’t count against uptime.

• Reports show uptime, downtime and incidents per monitor for this month, last month or the last 7, 30 or 90 days, against an SLA target of 99%, 99.5%, 99.9%, 99.95% or 99.99%, with a CSV download. The budget left is the allowed downtime minus the downtime in the report. See how to run reports against an SLA target.
• Incidents keep the evidence and a timeline of every check, alert and note, which is what a postmortem needs. See incident management.
• Maintenance windows keep planned work out of the numbers. See how to schedule maintenance windows.

To put a price on the budget you spend, try the downtime cost calculator. To see what each target allows, read what 99.9% uptime means.

Know how much budget you have left before the month is over. Try Uptimecheck free for 14 days, no credit card required.