Error Budget Calculator
Your error budget is the unreliability you are allowed before you miss your target. Enter a service level objective and a window to see the budget, how much is left, and whether your current pace will use it up early.
What an error budget is
An SLO (service level objective) is the success rate you aim for — say 99.9% of requests served, or 99.9% uptime. The error budget is everything left over: the 0.1% you are allowed to get wrong. Instead of treating every failure as unacceptable, you get a concrete allowance to spend on releases, migrations and experiments. While there is budget, you can move fast. When it is gone, you slow down and fix things.
How it is calculated
Error budget = (100% − SLO) × window size. As time, that is the window's minutes multiplied by (1 − SLO). As requests, it is the total requests in the window multiplied by (1 − SLO). Both describe the same target from different angles.
| SLO | Budget / 30 days | Budget / 90 days | Budget / 365 days |
|---|---|---|---|
| 99% | 7h 12m | 21h 36m | 3d 15h 36m |
| 99.9% | 43m 12s | 2h 9m 36s | 8h 45m 36s |
| 99.95% | 21m 36s | 1h 4m 48s | 4h 22m 48s |
| 99.99% | 4m 19s | 12m 58s | 52m 34s |
Burn rate
Burn rate compares how fast you are spending the budget with a pace that would last the whole window: burn rate = fraction of budget used ÷ fraction of window elapsed. At 1× you finish exactly on budget. At 3× you would use the entire month's budget in ten days. Alerting setups usually watch two windows at once — a fast burn (a large multiple over about an hour, page someone now) and a slow burn (a smaller multiple over several hours, open a ticket).
When the budget is gone
The point of the budget is the policy attached to it, agreed before you need it. The common one is a feature freeze: no new releases until reliability work brings the budget back in the next window. Other teams redirect a fixed share of engineering time to reliability, or require sign-off for any change while the budget is negative. Any rule works as long as everyone agreed to it in advance.
Frequently asked questions
What is an error budget?
It is the amount of unreliability you are allowed before you miss your target. If your SLO (service level objective) is 99.9% over 30 days, the error budget is the other 0.1% — about 43 minutes of downtime, or 0.1% of requests failing. You can "spend" it on risky releases, migrations and experiments.
How do you calculate an error budget?
Error budget = (100% − SLO) × the size of the window. As time: window minutes × (1 − SLO). As requests: total requests in the window × (1 − SLO). A 99.95% SLO over 30 days leaves about 21m 36s, or 0.05% of your request volume.
What is burn rate?
How fast you are spending the budget compared with a sustainable pace. Burn rate = (fraction of budget used) ÷ (fraction of window elapsed). 1× means you will finish the window exactly on budget. 2× means you are on track to use it all in half the window. Teams often alert on a fast burn (e.g. 14.4× over 1 hour) and a slow burn (e.g. 3× over 6 hours).
What happens when the error budget runs out?
That is a policy decision the team agrees in advance. A common one: stop shipping features and put engineering effort into reliability until the budget recovers in the next window. The budget turns "do not break anything" into a concrete, shared limit.
Should I use a time-based or request-based budget?
Request-based (event-based) is usually better when you can measure the success rate of individual requests, because it reflects real user impact. Time-based is simpler and works when you only have up/down monitoring. This calculator shows both.