Calculator Inputs
The page stays in a single vertical flow, while the input grid becomes three columns on large screens, two on medium screens, and one on mobile.
Example Data Table
| Service | SLO | Period | Total Requests | Failed Requests | Downtime | Observed Burn |
|---|---|---|---|---|---|---|
| Payments API | 99.90% | 30 days | 5,000,000 | 2,200 | 14 min | 0.44x |
| Search Service | 99.95% | 30 days | 12,000,000 | 9,100 | 18 min | 1.52x |
| Auth Gateway | 99.99% | 7 days | 18,000,000 | 620 | 3 min | 3.44x |
| File Uploads | 99.50% | 30 days | 800,000 | 1,900 | 20 min | 0.48x |
Formula Used
Allowed Error Rate = 100% - SLO Target
Allowed Failed Requests = Total Requests × Allowed Error Rate
Allowed Downtime Minutes = Period Minutes × Allowed Error Rate
Request Burn Rate = Actual Request Error Rate ÷ Allowed Error Rate
Downtime Burn Rate = Actual Downtime Percentage ÷ Allowed Error Rate
Projected Failures = Failed So Far ÷ Elapsed Minutes × Full Period MinutesProjected Downtime = Downtime So Far ÷ Elapsed Minutes × Full Period Minutes
Month and quarter selections use average calendar-length approximations. If your team uses request-based SLIs, those figures should drive policy decisions first.
How to Use This Calculator
- Enter a service name and your target SLO percentage.
- Choose the full reporting window, such as 7 days or 30 days.
- Enter elapsed time within the same measurement cycle.
- Add the total request volume expected for the whole period.
- Enter failed requests and downtime already observed.
- Add planned releases remaining if you want release pacing guidance.
- Click the calculate button to place the results above the form.
- Review remaining budget, burn rate, projection, and the graph before approving changes.
FAQs
1. What is an error budget?
An error budget is the amount of unreliability your service can consume while still meeting its SLO. Teams use it to balance reliability work against product velocity.
2. Why does the calculator show both failed requests and downtime?
Some teams measure user harm through bad requests, while others also track visible unavailability. Showing both helps engineering, operations, and release managers compare risk from two practical angles.
3. What does burn rate mean?
Burn rate shows how quickly you are spending budget compared with the allowed pace. A value above 1.00x means you are consuming reliability budget faster than planned.
4. What happens when the budget is exhausted?
Once the budget is exhausted, many teams slow releases, freeze risky changes, or prioritize reliability fixes. The exact policy depends on internal governance and customer expectations.
5. Why can projected exhaustion differ from current status?
Current status shows where you stand now. Projected exhaustion estimates where you may end the period if the present failure pace continues without improvement.
6. Should I trust downtime or request-based metrics more?
Use the metric that matches your formal SLI definition. If your SLI is request-based, request budget should lead policy. Downtime remains useful for incident communication and operations.
7. Why include planned releases remaining?
That field helps estimate how much request budget remains per upcoming release. It is a simple pacing aid for teams deciding how cautiously to ship during the rest of the window.
8. Can I use this for weekly, monthly, or quarterly reviews?
Yes. The calculator supports minutes through years, so it works for short incident windows, common 28 or 30 day SLO reviews, and broader quarterly planning sessions.