What the numbers mean
Allowed error ratio is 100% minus the target. A 99.9% target allows 0.1% of requests or minutes to be bad.
Budget as full outage converts that ratio to time: the window in minutes multiplied by the allowed ratio. It tells you how long a complete outage could last before the whole budget is gone. A partial failure spends budget more slowly, so a 10% error ratio spends it at one tenth of that speed.
Budget in failed requests is the same ratio applied to your traffic. It is usually the better number for request-based SLOs, because it stays meaningful for services with quiet hours.
Burn rate is the current error ratio divided by the allowed ratio. A burn rate of 1 spends exactly the whole budget by the end of the window. A burn rate of 5 on a 30-day window spends it in 6 days.
Budget for common targets
These figures use a 30-day window, which is 43,200 minutes.
| Target | Allowed error ratio | Full outage budget |
|---|---|---|
| 99% | 1% | 432 minutes (7.2 hours) |
| 99.5% | 0.5% | 216 minutes (3.6 hours) |
| 99.9% | 0.1% | 43.2 minutes |
| 99.95% | 0.05% | 21.6 minutes |
| 99.99% | 0.01% | 4.32 minutes |
Each extra nine cuts the budget by ten. At 99.99%, the budget is shorter than the time most on-call engineers need to open a laptop and read the alert. That target only works when recovery is automated, so set it deliberately.
How the alert table works
The table uses the four window pairs from The Site Reliability Workbook. An alert fires only when both the long window and the short window exceed the threshold. The long window shows that the problem is significant. The short window shows that it is still happening, which lets the alert resolve soon after recovery.
Error ratio over is the burn rate multiplied by your allowed ratio. With a 99.9% target, a burn rate of 14.4 means an error ratio above 1.44%.
Budget used when fired is the burn rate multiplied by the long window, divided by the SLO window. On a 30-day window, 14.4 × 1 hour / 720 hours is 2%. If you change the SLO window, the percentages change. The burn rates in the table were chosen for 30 days, so review them if you use a very different window.
When a target is low, a threshold can pass 100%. For example, a 90% target with a burn rate of 14.4 would need a 144% error ratio, which can never happen. The calculator shows 100% in that case, and you should choose a smaller burn rate for that alert.
Choosing inputs that reflect your users
- Measure what users feel. Successful requests served within a latency limit make a better SLI than host uptime.
- Use your real history. A target slightly tighter than what you achieved last quarter is a useful place to begin. A target you have never met will only produce constant alerts.
- Check low-traffic services. With 1,000 requests in the window and a 99.9% target, the budget is one failed request. Ratio alerts will be noisy, so use a longer window or a synthetic check.
- Agree on what happens when the budget runs out. A number without a decision behind it changes nothing. The error budget policy guide has a template.
How Wrentrix handles this
Wrentrix tracks SLOs with error budgets on your own infrastructure and raises multi-window burn-rate alerts with four window pairs, which resolve on their own once things calm down. You can see the screens in the live demo.
Frequently asked questions
How do I calculate an error budget?
Subtract the SLO target from 100% to get the allowed error ratio, then multiply it by the window or by your request count. A 99.9% target over 30 days allows 0.1% of 43,200 minutes, which is 43.2 minutes. With 10 million requests, it allows 10,000 failed requests.
What is a good burn rate alert threshold?
A common starting point is 14.4 over 1 hour with a 5-minute short window, and 6 over 6 hours with a 30-minute short window, both as pages. Burn rates of 3 and 1 over longer windows work well as tickets. Adjust them after reviewing a few months of alerts on your own service.
What does a burn rate of 1 mean?
It means you are spending budget at exactly the rate that uses all of it by the end of the SLO window. You would finish the window at the target with nothing left. Above 1, you will miss the target if the rate continues.
Should I use a 28-day or a 30-day window?
Both work. A 28-day window always contains four of each weekday, so comparisons between periods are fairer for services with weekly patterns. A 30-day window is easier to explain, and it lines up with the common month-based reporting.
Is my data sent anywhere?
No. The calculation runs in your browser with JavaScript, and the page does not send what you enter to any server.