Error budget review for release decisions

Use one review sheet for every release, then make the release decision from the same evidence each time. This gives engineering managers and reliability engineers a short record of whether the service can absorb more risk.

The output is one of three recommendations: proceed, defer, or proceed with safeguards. It is not a score. The recommendation must name the service-level objective, the remaining budget, the incidents that matter, and the specific release risk.

Set up the release review sheet

Create one document named Release error budget review - [service] - [release date]. Complete these fields before the decision meeting:

• Service and user journey: name the API, queue, worker or page affected. Name the user action, such as create invoice or submit order.
• Decision window: state the review period, such as the current 28-day SLO window, plus the last 7 days.
• SLO and indicator: copy the target and the measured indicator. Include the event definition, such as successful requests divided by eligible requests.
• Budget position: record allowed bad events, bad events used, budget remaining, and burn rate for the last hour, day and week.
• Recent incidents: list incidents in the last 30 days that touched the same dependency, failure mode or user journey.
• Planned change: state what will change, where it will run, which dependency it calls, and how it can fail.
• Controls: list the rollback trigger, owner, monitoring view, deployment pace and any feature flag or traffic limit.

Do not use a broad platform SLO when the release changes a narrower user journey. If the release changes payment authorisation, use the payment authorisation indicator. A general API availability measure can hide failures that matter to customers.

Calculate the budget position

Use the SLO definition already agreed for the service. For an availability objective, calculate the allowed bad-event count as:

eligible events × (1 - SLO target)

Then calculate:

budget remaining = allowed bad events - observed bad events

Record percentages and counts. Percentages show direction. Counts show whether a small percentage is still a large number of affected requests.

For each recent time range, record the burn rate: the observed rate of budget use divided by the rate implied by the SLO. A burn rate above 1 means the service is spending budget faster than the objective permits. Do not rely on a single graph point. Note whether the rate is sustained, rising, or linked to a completed incident.

If the service has several objectives, start with the one closest to the planned change. Add the others only where the change can plausibly affect them. A database migration may affect latency, availability and background-job freshness. Write each separately rather than combining them into one traffic-light status.

Connect incidents to the planned change

Read the incident summaries, not only the incident count. For each relevant incident, write four short lines:

1. Trigger: what changed or failed.
2. Customer effect: which user journey degraded and how the indicator showed it.
3. Detection gap: what alerted late, or did not alert.
4. Release overlap: which part of the planned change uses the same code path, dependency or operating condition.

Treat recurrence as evidence, not certainty. Three incidents caused by an upstream timeout matter more than ten unrelated deployment mistakes. Equally, do not describe an incident as unrelated without naming the boundary. For example, a cache incident may still matter if the release increases read volume or changes cache keys.

Choose the recommendation

Use the following decision rules. Write the matching recommendation at the top of the review sheet, followed by the evidence.

What you see	Recommendation	What must be written
Budget is stable, recent burn is below the expected rate, and no relevant unresolved incident exists	Proceed	Deployment owner, observation period and rollback trigger
Budget is exhausted, burn is sustained above the expected rate, or a relevant failure remains unexplained	Defer	The condition that must improve before reconsideration
Budget remains, but the release overlaps with a recent incident or has an uncertain failure mode	Proceed with safeguards	The safeguard, its owner, and the stop condition

Safeguards must change the release risk. “Watch dashboards” is not a safeguard. Use a smaller initial traffic share, a feature flag that removes the risky path, a staged database operation, a named on-call observer, or a pre-agreed rollback threshold tied to the service indicator.

Check for a misleading recommendation

Your review is wrong, or incomplete, if it has any of these signs:

• The budget was calculated from a different service, region or user journey than the release affects.
• The incident section says “no relevant incidents” but does not show which incidents were considered.
• The planned-change description is only a ticket title, with no dependencies or rollback path.
• A recommendation to proceed has no stop condition.
• A recommendation to defer does not say what evidence would change the decision.
• The team is using recovered availability to dismiss an active latency or correctness problem.

Ask a reviewer who did not prepare the sheet to trace one number back to the dashboard and one incident back to its write-up. If they cannot do this in a few minutes, the recommendation is not ready for a release meeting.

If you use the model you are using to turn dashboards and incident notes into a first draft, give it the raw figures, time ranges and incident links in the prompt. Ask it to identify missing fields, not to infer them. Its behaviour and available capabilities are version-dependent, so check the relevant details in the xAI documentation overview.

When the review does not produce a decision

Do not force a proceed or defer decision from missing data. Mark the sheet decision blocked, name the missing item, and assign an owner and deadline. Common blockers are an undefined indicator, an incident without a confirmed customer effect, or no tested rollback path.

For an urgent release, record why urgency outweighs the unknown, then use safeguards that reduce blast radius. Re-run the same review after the first deployment stage. The habit is the fixed evidence order: budget, recent burn, relevant incidents, planned change, controls, then recommendation.