Error Budget Calculator

TIMEBUDGET

Service or SLO name:

Optional filing label; it never changes the calculation.

SLO target:

Enter the success objective for this request- or event-based SLO.

Reporting window:

Use the full period against which the SLO is judged.

days

Elapsed window:

This cannot exceed the reporting window.

days

Eligible events observed:

Use the denominator from the same SLI slice as the bad-event count.

Budget-consuming events:

This count must use the same elapsed window and cannot exceed eligible events.

Release-watch gate:

Review higher-risk changes when projected use reaches this policy boundary.

{{ policy_watch_percent }}%

Slow-burn gate:

Use the threshold written in your team's SLO alert and release policy.

Fast-burn gate:

Use live monitoring to confirm a fast-burn incident; this calculator does not query telemetry.

Incident-share gate:

The 20% default mirrors one published Google SRE example policy.

{{ incident_budget_share_percent }}%

Expected period events:

Zero is neutral. A positive forecast cannot be below the eligible events already observed.

Metric	Value	Operational meaning	Copy
{{ row.metric }}	{{ row.value }}	{{ row.note }}

Gate	Threshold	Current	Next action	Copy
{{ row.gate }}	{{ row.threshold }}	{{ row.current }}	{{ row.action }}

Runway curve

Will the current bad-event pace overtake the sustainable budget path before the SLO window ends?

Reporting day	Projected budget used	Sustainable line	Projected budget remaining	Copy
{{ row.day }}	{{ row.projected }}	{{ row.sustainable }}	{{ row.remaining }}

An error budget turns a reliability objective into a finite allowance for unsuccessful events. If a request-based service level objective (SLO) is 99.9% successful, the remaining 0.1% is the failure allowance for the reporting window. That allowance gives product and reliability teams a shared way to discuss risk instead of treating every failure as equally urgent.

The count only has meaning when the numerator and denominator describe the same service level indicator (SLI). Failed checkout requests divided by all eligible checkout requests is coherent. Combining failures from one route, region, or time span with traffic from another can make a healthy service look risky or conceal a real miss.

Budget used: The observed bad-event count as a share of the full-window failure allowance.
Burn rate: Observed error ratio divided by the allowed error ratio. A burn rate of 1 consumes budget at the sustainable rate; 10 means ten times that pace.
Runway: A straight-line estimate of when the allowance would be exhausted if the observed bad-event pace continued.

These measures support different decisions. Current budget use shows what has already been spent, projected use shows where the window is heading, and burn rate exposes an intense short-period failure rate even when the total budget is still large. A release policy may react to any of them, so its thresholds should be written before an incident rather than improvised during one.

A projection is not telemetry or a forecast of user behavior. Traffic, error rates, and failure clustering can change abruptly, and the same number of failed requests may produce very different user harm depending on who was affected and for how long. Error-budget arithmetic should guide a documented reliability policy, not replace live monitoring, incident review, or judgment about user impact.

How to Use This Tool:

Start with one SLI slice and one reporting window, then compare its observed pace with your team's policy gates.

Enter the SLO target, full Reporting window, and Elapsed window. The elapsed value must be greater than zero and no longer than the full window.
Enter Eligible events observed and Budget-consuming events from the same query and time slice. The bad-event count cannot exceed the eligible count.
Set the Release-watch gate, Slow-burn gate, Fast-burn gate, and Incident-share gate to match the written policy you actually enforce.
Use Expected period events when a credible full-window traffic forecast exists. Leave it at zero to extend the observed traffic pace across the reporting window.
Review the headline state with the Policy review. Confirm any fast-burn signal in live monitoring before pausing a release or declaring an incident.

Interpreting Results:

Available means projected use is below 100% and neither the release-watch nor slow-burn gate has been reached. An incident-share gate may still call for review.
Watch means projected use is at or above the release-watch percentage, or burn rate is at or above the slow-burn multiple.
Spent means the remaining event allowance is zero or less, or constant-pace projected use is at least 100%.
A negative runway means the modeled exhaustion day is already behind the elapsed point. A low-sample warning means the observed event count contains fewer than ten allowed failures at the selected SLO, so a handful of events can move the ratios sharply.

Technical Details:

Request-based error-budget accounting starts with an allowed failure ratio and a projected full-window denominator. When no traffic forecast is supplied, the observed event rate is extended linearly through the rest of the period. Bad events are projected independently from their observed daily pace.

Formula Core:

The core equations keep the SLO, observed error ratio, full-window budget, and pace projection explicit.

\begin{array}{lcl} a & = & 1 - \frac{S}{100} \\ N_{p} & = & \frac{N}{e / P} \\ B & = & N_{p} \times a \\ r & = & \frac{b / N}{a} \\ U_{p} & = & \frac{(b / e) P}{B} \times 100 \end{array}

S is the SLO percentage, a is the allowed failure ratio, N is eligible events observed, b is bad events, e is elapsed days, P is period days, N_p is projected period events, B is the full-window event budget, r is burn rate, and U_p is projected budget use in percent. A supplied Expected period events value replaces the linear traffic projection for N_p.

For 12.5 million eligible events and 8,200 bad events after 10 days of a 30-day window at a 99.9% SLO, observed traffic projects to 37.5 million events. The full-window allowance is 37,500 bad events, current use is about 21.87%, burn rate is 0.656, and constant-pace projected use is 65.6%.

Rule Core:

All policy comparisons are inclusive. Reaching a gate is enough to trigger it.

Error budget policy and state rules
Rule	Trigger	Effect
Release watch	Projected budget used ≥ selected watch percentage	Raises the state to Watch unless already Spent.
Slow burn	Burn rate ≥ selected slow-burn multiple	Raises the state to Watch unless already Spent.
Fast burn	Burn rate ≥ selected fast-burn multiple	Flags urgent live-monitoring confirmation; it does not independently select the headline state.
Incident share	Current budget used ≥ selected incident-share percentage	Flags policy review for the observed slice.
Spent	Remaining budget ≤ 0 or projected use ≥ 100%	Overrides Available and Watch.

Runway assumes a constant bad-event rate of b/e. The modeled exhaustion day is B ÷ (b/e), and days remaining subtract the elapsed window. The five runway points cover 0%, 25%, 50%, 75%, and 100% of the reporting period. Counts remain mathematically continuous in the model and are rounded only for display.

Accuracy Notes:

The result is deterministic but only as representative as the SLI slice and traffic assumption. It does not query monitoring data, recognize maintenance exclusions, model changing traffic or error rates, or measure how failures were distributed among users.

Use the same inclusion rules for eligible and bad events, including region, route, status classification, and elapsed time.
Replace observed-pace traffic with a defensible full-window forecast when launches, seasonality, or scheduled events make traffic nonstationary.
Keep policy thresholds aligned with alert rules and release governance; the defaults are examples, not universal SRE standards.
The calculation runs in the browser. Share exported results according to your organization's handling rules for service and incident data.

Worked Examples:

One-day fast burn

A 99.9% SLO records 1,000,000 eligible events and 12,000 bad events on day 1 of a 30-day window. The 1.2% observed error ratio is 12 times the allowed 0.1%, so a 10x fast-burn gate is crossed. Constant pace projects 1,200% budget use and exhaustion on day 2.5, making live incident confirmation more important than the still-positive current event balance.

References:

Implementing SLOs, Google Site Reliability Engineering Workbook.
Alerting on SLOs, Google Site Reliability Engineering Workbook.
Example Error Budget Policy, Google Site Reliability Engineering Workbook, 2018.