Error-budget template: calculations and release-policy fields

The worksheet says 350 failed requests remain in the allowance. A repair is waiting to ship. Who can decide what happens next? This template puts the reproducible calculation and the release agreement together, because the number alone cannot answer that second question.

Begin with one operation users rely on. Its service-level objective, or SLO, implies an allowance for bad outcomes called an error budget. Define that outcome before entering the percentage, so the calculation and policy protect the same experience.

The SLO measurement record

The service-level indicator, or SLI, measures that experience. A good event might be an eligible request finishing within 300 milliseconds. At a 95% target, 5% of those requests may be bad. That is not permission for the service to be completely unavailable for 5% of the month.

The population is the work covered by the promise. Omitting requests can improve a percentage without improving service. Keep eligible requests, window and freshness beside the query so two people reproduce the same result.

If owners disagree on the experience being protected, record that disagreement. A spreadsheet can calculate many decimal places before the team has answered the more important question.

Worked calculations in requests and minutes

For event-based objectives, multiply eligible events by one minus the target fraction. Subtract observed bad events from that allowance. A negative remainder means the allowance was exceeded and the objective was not met for that window.

In the first example, one million requests at 99.9% allows 1,000 failures; 650 observed leaves 350. The second uses the same arithmetic but calls requests slower than 300 milliseconds bad. Keeping all four counts visible makes the answer checkable.

Time-based availability uses different units. Across exactly thirty days, 99.9% allows 43.2 bad minutes; 99.95% allows 21.6; 99.99% allows 4.32. Another month's length changes these amounts. Partial failed requests do not convert directly into outage minutes without redefining the measure.

Missing collection leaves uncertainty no arithmetic can remove. Record the missing period and the numerator or denominator it affects. Correctly summing received records may still fail to cover the intended population, so the policy needs a rule for absent or stale evidence.

Keep the allowance in request units

Read diagram description

Worked example: one million eligible requests at a 99.9% success target allow 1,000 bad requests. With 650 observed bad requests, 350 remain. Missing collection coverage can invalidate the decision even when the arithmetic is correct.

Release-policy fields

Policy owner: [team and accountable decision maker]
Applies to: [services and release paths]
Normal state: [conditions and permitted changes]
Review state: [burn/remaining-budget conditions and required review]
Hold state: [conditions and changes paused]
Missing or stale telemetry: [hold, review, or other explicit behavior]
Permitted exceptions: [bounded categories and approver]
Resumption: [health evidence, observation window, and approval]
Policy review date: [date and triggers for earlier review]

Now imagine the allowance runs out with a release queued. Say which work pauses, who reviews it, how an exception proceeds and what allows ordinary releases to resume. Include missing telemetry. These fields turn the result into an agreement someone can use.

Choose thresholds from workload and incident evidence. Google's alerting guidance develops multiple observation windows and the care needed with low volumes. The blank fields remain decisions for this service, not invitations to copy another one's numbers.

In a hypothetical completed worksheet, the arithmetic is right but the exception-owner field is blank. A security repair waits while the team negotiates authority. The sheet has answered how much remains but not who can act on it.

Try that case with the normal approver unavailable. Who takes over, and how do they learn why the budget was exhausted? Then remove fresh telemetry and follow the written rule. Both rehearsals test the agreement before a pipeline enforces it.

The exception record and its outcome

Keep the exception's change identifier, reason, scope, evidence, benefit, approver, expiry and later outcome together. If follow-up remains, name its owner and the evidence that would establish improvement. Do not replace that question with an unsupported improvement percentage.

Before enforcement, reproduce the arithmetic, test no traffic and rehearse a repair needing an exception. Check that people can actually be reached. The release-gate guide covers implementation once the agreement works.

Return to the waiting security repair. The reader should be able to find the exhausted allowance, an available decision-maker and the observations needed to resume normal work. If authority is still blank, repair that agreement. Additional decimal places will not supply it.