Key takeaway
An error budget is relative to a defined service objective and eligible events. Preserve its policy and windows; incident count cannot reconstruct the allowance.
Start with the policy, not the incident total
An incident archive can explain what failed and how service recovered without showing how much of a service objective’s allowance was consumed. One long incident and several short incidents need not have the same eligible-event impact. Before describing a history as within budget, locate the service-level indicator, goal, population and window behind that statement.
Google Cloud defines the error budget for a compliance period as one minus the SLO goal, multiplied by the eligible events in that period. This article uses a request-based example. A percentage of bad requests is not automatically a duration of downtime, and the same arithmetic should not be silently transferred to a window-based indicator. The owner must identify what one eligible event means.
Complete a fixed-period request ledger
This hypothetical policy defines good requests for a specified service, fixes a completed observation period and sets a 99.9% goal. Its retained counts are 100,000 eligible requests and 50 bad requests. The permitted bad fraction under that goal is 0.001, so the period’s allowance is 0.001 times 100,000, or 100 bad requests. The 50 observed bad requests consume 50% of that allowance.
A separate short alert window within the period contains 2,000 eligible requests and four bad requests. Its bad fraction is 4 / 2,000 = 0.002. Dividing by the policy’s allowed fraction of 0.001 gives normalized burn of 2. That is a short-window rate comparison, not the statement that the entire fixed period has consumed twice its budget.
| Evidence | Completed toy value | Meaning under the declared policy |
|---|---|---|
| Goal and allowed fraction | 99.9% good; bad fraction 0.001 | Request-based objective, not a downtime formula |
| Fixed-period eligible requests | 100,000 | Declared population for this allowance |
| Allowance and observed bad | 100 allowed; 50 observed | 50 / 100 = 50% consumed |
| Separate short window | 2,000 eligible; 4 bad | Observed bad fraction 0.002 |
| Normalized short-window burn | 0.002 / 0.001 = 2 | Rate comparison, not whole-period consumption |
| Incident tracker | One closed incident | Insufficient to reproduce either calculation |
A burn rate is not an exhaustion date
Google’s SRE Workbook explains burn relative to a goal and uses different alert windows to detect different consumption patterns. Its 99.9% example associates burn 1 with a 0.1% error rate under the stated window. The source also discusses limitations for low-traffic services. Keep those conditions when borrowing its arithmetic; do not copy an alert threshold as a universal policy.
The hypothetical burn of 2 describes the measured short window relative to this policy’s allowed bad fraction. It does not establish that the same error rate, traffic, exclusions or service scope will persist. Without those assumptions, the owner should not project a calendar date when budget will run out. The observed 50% consumption and short-window burn are both retained, with their different denominators and purposes.
A rolling compliance window introduces another interpretation question because the included events change as time moves. Retain the actual window selection with the result. Do not attach a calculation made for a completed fixed period to a rolling dashboard simply because both displays show the same SLO goal.
Keep the eligibility rule reproducible
The internal artifact should state the service scope, policy version, good/bad predicates, eligible-event rule, compliance window and alert window. Identify how excluded traffic, unknown classifications and retained counter gaps are handled under the actual policy. Do not turn an unclassified event into good just to reconcile the headline.
For this example, the owner can reproduce the allowance and both ratios because the counts and policy are declared. In an actual archive, a final percentage without eligible counts may support only a historical dashboard description. A closed incident without the indicator history cannot recreate how the SLO calculation treated affected requests. Ask for missing evidence before promising an externally reproducible reliability history.
Return the policy-relative conclusion
The completed decision reports 50% of the fixed example’s allowance consumed and a separately defined short-window burn of 2. It holds any exhaustion-date prediction and makes no claim about a real service. No paging rule, operational change or uptime warranty is approved. The record distinguishes the observed counts from a forecast and the declared policy from a universal standard.
Use Inventory to describe the retained policy and indicator layers and Due diligence to identify the recipient’s intended question. Request payloads, customer identities and security-sensitive service detail need separate review before disclosure. A fictional ledger can explain the mechanism first. VOID’s permissioned introduction does not certify reliability or authorize later access, evaluation or licensing of the service history.