Error Budget and SLO Calculator

Error budget = (100% − SLO) × window. A 99.9% SLO over 30 days allows 0.1% of 2,592,000 seconds, which is 43 minutes 12 seconds of downtime, or 1 failed request in every 1,000. Burn rate is the observed error rate divided by that budget: at 14.4× the whole 30-day budget is gone in 50 hours. Enter your SLO below to get allowed downtime, allowed failed requests and burn-rate times, and the error-rate threshold your load tests should use.

The formulas

budget            = 1 − SLO                       (99.9% → 0.001)
allowed_downtime  = window_seconds × budget
allowed_failures  = requests_in_window × budget
burn_rate         = observed_error_rate / budget
time_to_exhaust   = window / burn_rate
budget_per_hour   = burn_rate / window_hours

Allowed downtime applies to time-based SLOs ("the service is up 99.9% of minutes"). Allowed failures applies to request-based SLOs ("99.9% of requests succeed"), which most teams use for HTTP services because they weight busy hours more than quiet ones. The calculator scales the 30-day request volume to the selected window, so 50 million requests per 30 days becomes 46.7 million for a 28-day window.

Burn rate is the most useful number for day-to-day decisions. It normalizes any error rate against the budget: a burn rate of 1 consumes the budget exactly over the window, 2 consumes it in half the window, and so on.

Allowed downtime by SLO and window

Values are rounded to the nearest second. Each extra nine cuts the budget by 10×. At 99.99% over 30 days you have about four minutes a month, which is less than many deploy pipelines take to roll back a bad release.

Worked example

An illustrative API with a 99.9% request-based availability SLO over a rolling 30 days, serving 50 million requests in that period (the calculator defaults):

1. Budget: 1 − 0.999 = 0.001, or 0.1%.
2. Allowed failures: 50,000,000 × 0.001 = 50,000 failed requests per 30 days.
3. Allowed downtime equivalent: 2,592,000 s × 0.001 = 2,592 s = 00:43:12.
4. Load test result: the test at expected peak shows a 0.5% error rate. Burn rate = 0.5% ÷ 0.1% = 5×.
5. Consequence: if production behaved like the test at peak around the clock, the budget would last 30 ÷ 5 = 6 days. In reality the peak lasts a few hours a day, but it still eats budget five times faster than allowed during those hours.

That test should not pass. It is not a dramatic failure, but it shows the service cannot meet its SLO at expected peak load.

Burn rates and alerting

The burn rates in the calculator's table (1×, 2×, 6×, 14.4×) come from the multi-window, multi-burn-rate alerting approach in Google's SRE Workbook. The idea is to alert on how much budget a burn consumes over a period, not on a raw error rate:

The math: budget consumed = burn rate × duration ÷ window. 14.4 × 1 h ÷ 720 h = 0.02. The Workbook pairs each long window with a short one (for example 1 hour and 5 minutes) so the alert also stops firing quickly once the problem is fixed. If you use a 28-day window the same burn rates consume slightly more budget per hour; the calculator's last column shows that directly.

Turning the budget into load test thresholds

A load test is a controlled preview of how fast you would burn budget at a given traffic level. That gives you a defensible error-rate threshold instead of a round number picked by habit:

• At expected peak (steady state): error rate ≤ budget, meaning burn rate ≤ 1. For a 99.9% SLO, the threshold is 0.1%. Peak hours are when most budget is spent, so this is the stage that matters.
• At peak plus headroom (1.5× to 2×): some degradation can be acceptable, for example burn ≤ 2 (0.2% errors at 99.9%). Decide this in advance and write it down.
• Stress and spike stages: do not gate on error rate; record where errors start and how the system recovers. See the spike testing and stress testing guides.

Compare that with the common default of "error rate below 1%" or "below 2%". For a 99.9% service, 1% is a 10× burn and 2% is 20×; at 20× a 30-day budget lasts 36 hours. Those thresholds are reasonable for a 99% SLO and too loose for anything stricter.

In LoadTester you can set an error-rate threshold on a test (for example error rate < 0.1%) alongside a p95 threshold and have the run auto-stop on breach. The same values work as k6 thresholds:

// 99.9% availability SLO, 300 ms p95 latency SLO
export const options = {
  thresholds: {
    http_req_failed:   ['rate<0.001'],
    http_req_duration: ['p(95)<300'],
  },
};

Latency SLOs work the same way. "95% of requests under 300 ms" has a 5% budget of slow requests; the latency percentile calculator shows whether your test met it, and p95 vs p99 latency covers which percentile to choose.

Define errors the same way in production and in the test

The threshold is only meaningful if the load test counts errors the way your SLI does:

• 5xx and timeouts count in almost every availability SLI. Make sure the load test's timeout matches the client timeout your users actually have, not a generous 60 seconds.
• 4xx usually do not count, because the client caused them. A load test that produces many 401s or 404s has a broken script, not a broken service. Fix the script first.
• 429 Too Many Requests is ambiguous. If your own rate limiter rejects real users at peak, that is lost availability. If the load generator is hitting a per-IP limit that real users never would, allowlist it. See rate limit testing.
• Connection errors from the load generator itself (port exhaustion, too many open files) are not service errors. Check the generator before blaming the target.

Checklist

1. Write down the SLO, window and SLI definition (which status codes count, which timeout).
2. Use the calculator to get the budget and the burn-rate-1 error rate.
3. Set the load test threshold at expected peak to that error rate, and a looser one for the headroom stage if you agreed on it.
4. Add a latency threshold from the latency SLO.
5. Run the test regularly, not once: continuous load testing catches regressions before they spend budget in production.