Calculator Inputs
The page stays single-column, while this input grid uses three columns on large screens, two on smaller screens, and one on mobile.
Example Data Table
| Scenario | SLO | Window | Total Requests | Successful Requests | Downtime | Remaining Days | Budget Status |
|---|---|---|---|---|---|---|---|
| Payments API | 99.95% | 30 days | 12,000,000 | 11,997,900 | 14 min | 10 | Watch Closely |
| Search Gateway | 99.90% | 28 days | 48,500,000 | 48,492,600 | 11 min | 7 | Healthy |
| Checkout Edge | 99.99% | 7 days | 31,000,000 | 30,996,300 | 9 min | 2 | Critical Burn |
Formula Used
Error Fraction = 1 − (SLO Target ÷ 100)
Allowed Bad Requests = Total Requests × Error Fraction
Allowed Downtime = Window Minutes × Error Fraction
Request Reliability = Successful Requests ÷ Total Requests × 100
Time Reliability = 100 − (Downtime Minutes ÷ Window Minutes × 100)
Consumption = max(Request Budget Used, Downtime Budget Used)
Burn Rate = Consumption Fraction ÷ Elapsed Window Fraction
The calculator intentionally surfaces the stricter of request-based and time-based consumption, because teams usually need to act on the first budget dimension that becomes risky.
How to Use This Calculator
- Enter the service objective as an availability target percentage.
- Choose the reporting window, or define a custom number of minutes.
- Provide total requests, successful requests, and total downtime already observed.
- Add incident count, MTTR, deployments, and remaining days for deeper operational context.
- Press the calculate button to show results below the header and above the form.
- Review the primary limiting dimension, projected end consumption, and burn-rate status.
- Export the visible results as CSV or PDF for reviews, retrospectives, or release approvals.
Frequently Asked Questions
1. What is an error budget?
An error budget is the allowed amount of unreliability within a target window. It translates an SLO into tolerated bad requests or downtime.
2. Why does the calculator track both requests and downtime?
Some teams manage reliability through successful request rates, while others focus on downtime. Showing both reveals which limit is being consumed faster.
3. What does burn rate mean here?
Burn rate shows how quickly the budget is being spent relative to elapsed time. A burn rate above one means consumption is faster than planned.
4. Why can a service be healthy in one metric but risky overall?
A platform may have strong request success but still spend downtime too quickly, or the reverse. The strictest dimension usually drives the operational risk.
5. How should teams use projected end consumption?
Use it to estimate where the window will end if current behavior continues. It helps decide whether launches, experiments, or freeze periods are justified.
6. What happens when the budget is exceeded?
The calculator marks the service as exceeded. Teams usually pause risky changes, reduce incident drivers, and prioritize recovery or reliability engineering work.
7. Is remaining budget per day useful for planning?
Yes. It turns a total allowance into a daily operating guardrail, which is easier to apply during on-call reviews and deployment planning.
8. Can I use a custom analysis window?
Yes. Select the custom window option and enter total minutes. This works well for internal reporting cycles or special release observation periods.