Error Budget Impact Analysis Prompt

This prompt is designed for SRE and product engineering teams who need a precise, data-driven assessment of an incident's impact on a Service Level Objective (SLO). The core job-to-be-done is translating raw incident telemetry—duration, error rate, and the SLO target—into a clear financial-style accounting of your error budget. It answers three critical questions: exactly how much budget was consumed, how many days of normal operation remain before exhaustion, and whether the remaining budget triggers a policy action like a feature freeze. Use this during post-incident review or as part of a change advisory board process to replace gut-feel decisions with quantitative evidence.

To use this effectively, you must have accurate, pre-defined SLO targets and monitoring data for the incident window. The prompt expects structured inputs: the SLO target percentage (e.g., 99.9%), the duration of the incident in minutes, and the measured error rate during that window. It does not perform real-time analysis or trigger automated rollbacks; it is a post-hoc planning tool. Do not use this prompt if your monitoring data is incomplete, if the SLO definition is disputed, or if you need a real-time alerting decision. The output is a structured calculation of budget consumption, a projection of days until exhaustion at the current burn rate, and a clear recommendation (e.g., 'Freeze releases', 'Accelerate fixes', 'No action required').

Before running this prompt, validate your inputs against your monitoring system of record. A common failure mode is using a point-in-time error rate that doesn't represent the full incident window, leading to an underestimation of budget impact. For high-severity incidents, always have a second engineer independently verify the input numbers. The prompt's output should be logged alongside the incident record for auditability. If the calculation shows budget exhaustion is imminent, the next step is to escalate to the product and engineering leadership with the specific projection, not to rely on the prompt alone to make the freeze decision.

This prompt template accepts structured incident data from your monitoring system and produces a quantified error budget impact analysis. It is designed to be wired into an SRE automation harness where incident duration, error rate, and SLO targets are known at runtime. The template uses square-bracket placeholders that your application must populate before sending the request. Do not use this prompt for real-time incident response decisions without human review of the output—the calculation is deterministic but the interpretation of whether to freeze releases or accelerate remediation requires business judgment.

textCopy
You are an SRE error budget analyst. Given the incident data below, calculate the error budget impact and produce a structured analysis.

## INPUT DATA
- Incident ID: [INCIDENT_ID]
- Incident Start Time: [START_TIME]
- Incident End Time: [END_TIME] (use 'ongoing' if still active)
- Error Rate During Incident: [ERROR_RATE_PERCENT]
- Service SLO Target: [SLO_TARGET_PERCENT]
- Error Budget Window: [BUDGET_WINDOW_DAYS] days
- Total Requests in Window (estimated): [TOTAL_REQUESTS]
- Error Budget Consumed Before Incident: [PRIOR_CONSUMPTION_PERCENT]
- Burn Rate Threshold for Alert: [BURN_RATE_THRESHOLD]

## OUTPUT REQUIREMENTS
Produce a JSON object with this exact schema:
{
  "incident_id": string,
  "duration_minutes": number,
  "error_budget_consumed_percent": number,
  "total_error_budget_consumed_percent": number,
  "remaining_budget_percent": number,
  "burn_rate_multiple": number,
  "projected_exhaustion_days": number or null,
  "recommendation": "freeze_releases" | "accelerate_remediation" | "monitor" | "no_action",
  "calculation_notes": string,
  "assumptions": [string]
}

## CALCULATION RULES
1. Duration = (end - start) in minutes. If end is 'ongoing', use current time.
2. Error budget consumed = (error_rate - (1 - SLO_target)) * (incident_requests / total_window_requests) * 100
3. Incident requests = (duration_minutes / (window_days * 1440)) * total_requests
4. Total consumed = prior_consumption + error_budget_consumed
5. Remaining = 100 - total_consumed
6. Burn rate = error_budget_consumed / (duration_minutes / (window_days * 1440) * 100)
7. Burn rate multiple = burn_rate / (100 / (window_days * 1440))
8. Projected exhaustion = if burn_rate_multiple > 0, (remaining / (burn_rate_multiple * 100 / (window_days * 1440))) / 1440, else null
9. Recommendation: 'freeze_releases' if remaining < 10 OR burn_rate_multiple > [BURN_RATE_THRESHOLD]; 'accelerate_remediation' if remaining < 25; 'monitor' if remaining < 50; else 'no_action'

## CONSTRAINTS
- Show all calculations in calculation_notes for auditability.
- List any assumptions made when input data is incomplete.
- If the incident is ongoing, note that projections are preliminary.
- Round percentages to 2 decimal places.
- If any required input is missing, return an error object: {"error": "missing_input", "missing_fields": [string]}

To adapt this prompt for your environment, replace each bracketed placeholder with live data from your monitoring stack. The [ERROR_RATE_PERCENT] should come from your service-level metrics during the incident window, not the overall error rate. The [PRIOR_CONSUMPTION_PERCENT] must be pulled from your error budget tracking system to avoid double-counting. If your SLO uses a request-based rather than time-based window, adjust the calculation rules accordingly and update the [TOTAL_REQUESTS] placeholder to reflect actual observed volume. For ongoing incidents, wire your harness to re-run this prompt every 15 minutes with updated duration and error rate values, and flag any recommendation change as an alert. Always log the full prompt input and output for post-incident audit trails.

This prompt is designed to be called programmatically within an incident management or postmortem automation pipeline, not as a one-off chat interaction. The primary integration point is a webhook or scheduled job triggered by an incident declaration, a significant SLO breach alert, or a post-incident review state change. The application layer must gather the required inputs—[SLO_TARGET], [BUDGET_WINDOW], [INCIDENT_START_TIME], [INCIDENT_END_TIME], [ERROR_RATE_DURING_INCIDENT], and [NORMAL_ERROR_RATE]—from your observability stack (e.g., querying Prometheus, Datadog, or your SLO tracking service) before assembling the prompt. Do not rely on a human to manually calculate or copy these values; the harness should fetch them to ensure accuracy and consistency.

After the model returns its analysis, the implementation must run a strict post-processing validation step before the output is surfaced to any user or used to trigger an automated action like a feature freeze. The validation logic should: (1) parse the model's JSON output and confirm it matches the [OUTPUT_SCHEMA]; (2) independently recalculate the error budget consumed using the same input metrics and compare it to the model's error_budget_consumed_percent value, flagging any discrepancy greater than 1%; (3) verify that the remaining_budget_hours is mathematically consistent with the budget_window_days and consumption rate; and (4) check that the recommended_action field is one of the allowed enum values. If validation fails, the harness should log the raw response, the validation error, and the input parameters, then either retry with a lower temperature or escalate to an on-call engineer for manual review. For high-severity incidents where the error budget is critically low, always require a human to approve any automated freeze or remediation action before it is executed.

Model choice matters for this workflow. The prompt requires precise arithmetic reasoning and strict schema adherence, so prefer a leading model with strong JSON mode and function-calling capabilities. Set temperature to 0 or a very low value (e.g., 0.1) to minimize variance in calculations. The prompt should be sent with a response_format constraint set to json_schema if the provider supports it, using the defined [OUTPUT_SCHEMA] as the expected structure. Avoid using this prompt with small or quantized open-weight models that are prone to arithmetic errors; if you must, add a calculator tool to the harness and modify the prompt to instruct the model to use the tool for all percentage and duration calculations rather than performing them in its head. Log every invocation with the full prompt, model response, validation result, and any human approval decisions to create an audit trail for compliance and postmortem review.