Error Budget Burn Rate Verification Prompt

This prompt is designed for Site Reliability Engineers (SREs) and platform operators who need to verify the impact of a recent change, deployment, or incident on their Service Level Objective (SLO) error budget. It takes raw metric data and a defined SLO window, then generates a structured burn rate analysis, a projection for budget exhaustion, and a risk classification. Use this prompt after a deployment, a configuration change, or an incident remediation to close the verification loop. It is not a replacement for your monitoring dashboard; it is a reasoning tool that interprets the data you provide and recommends whether to escalate to a human for a rollback or remediation decision.

The ideal user provides a specific, bounded context: a target SLO percentage, the length of the compliance window (e.g., 30 days), and a time-series dataset of error counts and total requests. The prompt is most effective when you need a fast, structured interpretation of whether the current burn rate is sustainable. For example, after a canary deployment, you can pipe the canary's error metrics into this prompt to get an immediate read on whether the deployment is consuming the error budget at an acceptable rate, or if it's on a trajectory to exhaust the budget within hours, triggering an automatic escalation recommendation.

Do not use this prompt for real-time alerting or as a substitute for your Service Level Indicator (SLI) metrics pipeline. It is not designed to ingest raw log streams or make sub-second decisions. Avoid using it when the SLO window is undefined, the input data is not pre-aggregated into a time series, or when the decision to roll back requires complex orchestration logic that goes beyond a risk classification. The prompt's output is a reasoned recommendation, not an executable command. In high-severity scenarios, the final decision to roll back or remediate must always remain with a human operator who can weigh factors outside the prompt's context, such as business impact or upcoming peak traffic.

The following prompt template is designed to be copied directly into your AI harness. It accepts structured inputs for SLO definitions, recent event data, and risk thresholds, then produces a verification report that includes burn rate calculations, projections, and an escalation recommendation. All placeholders use square-bracket notation so you can wire them into your application's variable substitution layer without ambiguity.

textCopy
You are an SRE verification assistant. Your task is to analyze error budget burn after a recent change and produce a structured verification report.

## INPUT DATA
- SLO Definition: [SLO_DEFINITION]
- Compliance Window: [COMPLIANCE_WINDOW]
- Error Budget Policy: [ERROR_BUDGET_POLICY]
- Recent Change Details: [CHANGE_DETAILS]
- Pre-Change Error Rate (last [PRE_WINDOW]): [PRE_CHANGE_ERROR_RATE]
- Post-Change Error Rate (last [POST_WINDOW]): [POST_CHANGE_ERROR_RATE]
- Current Error Budget Remaining: [CURRENT_BUDGET_PERCENT]
- Alert History (last [ALERT_WINDOW]): [ALERT_HISTORY]

## OUTPUT SCHEMA
Return a single JSON object with this exact structure:
{
  "report_id": "string",
  "generated_at": "ISO8601 timestamp",
  "change_reference": "string",
  "burn_rate_analysis": {
    "pre_change_burn_rate": "number (budget % consumed per hour)",
    "post_change_burn_rate": "number (budget % consumed per hour)",
    "burn_rate_multiplier": "number",
    "calculation_method": "string explaining the formula used"
  },
  "projection": {
    "time_until_exhaustion_at_current_rate": "string (e.g., '3 days, 4 hours')",
    "projected_budget_remaining_at_window_end": "number (percentage)",
    "assumptions": ["string"]
  },
  "risk_classification": "low | medium | high | critical",
  "escalation_required": true or false,
  "escalation_reason": "string or null",
  "verification_passed": true or false,
  "evidence_summary": ["string"],
  "recommendations": ["string"]
}

## CONSTRAINTS
- Use the compliance window from the SLO definition for all projections.
- If the post-change burn rate exceeds [BURN_RATE_THRESHOLD]x the pre-change rate, classify risk as "high" or "critical".
- If projected budget remaining at window end falls below [BUDGET_EXHAUSTION_THRESHOLD]%, set escalation_required to true.
- If any alert in the alert history has severity "critical" and occurred after the change, include it in evidence_summary.
- Do not fabricate metric values. If a calculation cannot be performed due to missing data, set the field to null and note the gap in assumptions.
- All timestamps must be in ISO8601 format.

## RISK CLASSIFICATION RULES
- "low": post-change burn rate <= pre-change burn rate and projection shows >50% budget remaining at window end.
- "medium": post-change burn rate > pre-change burn rate but projection shows >[BUDGET_EXHAUSTION_THRESHOLD]% budget remaining.
- "high": projection shows <=[BUDGET_EXHAUSTION_THRESHOLD]% budget remaining at window end.
- "critical": budget exhaustion projected within [CRITICAL_EXHAUSTION_HOURS] hours.

## ESCALATION RULES
- Set escalation_required to true if risk_classification is "high" or "critical".
- Set escalation_required to true if any evidence_summary item indicates a critical alert.
- When escalation_required is true, escalation_reason must contain a specific, actionable explanation referencing the burn rate, projection, or alert evidence.

To adapt this template, replace each square-bracket placeholder with values from your observability stack. The [SLO_DEFINITION] should include the target SLO percentage and the compliance window duration. Wire [BURN_RATE_THRESHOLD] and [BUDGET_EXHAUSTION_THRESHOLD] to your team's error budget policy—typical starting values are 2x for burn rate threshold and 10% for budget exhaustion threshold. The [CRITICAL_EXHAUSTION_HOURS] field defines your fast-burn emergency boundary; 24 hours is a common default for critical services. Before deploying, validate that your substitution layer handles missing optional fields gracefully and that the output JSON parses correctly against the schema.

After copying the template, pair it with a validation step that checks the output JSON against the declared schema. If the model produces malformed JSON or omits required fields, use a repair prompt from the Output Repair and Validation Prompts pillar rather than retrying blindly. For production deployments, log every verification report with the input parameters that produced it so you can audit burn rate calculations later. If the prompt is used in a regulated environment, require human review for any report where escalation_required is true before the report triggers an automated rollback or paging action.

This prompt is designed to be called after a change event (deployment, config push, feature flag toggle) as part of an automated verification pipeline. The application harness should fetch the relevant SLO definitions, error budget status, and time-series metrics from your observability platform (e.g., Datadog, Prometheus, Cloud Monitoring) and inject them into the prompt's [SLO_DEFINITION], [CURRENT_BUDGET], and [METRICS_WINDOW] placeholders. The model is not querying your metrics system directly; the harness is responsible for gathering the raw data and presenting it as structured context. This separation ensures the model reasons over a known, auditable snapshot rather than making live API calls with unbounded scope.

The harness must enforce a strict output contract. Parse the model's JSON response and validate it against the expected schema before any downstream action. Key validation checks include: (1) burn_rate_multiplier is a positive float and matches the math (error_rate / error_budget_rate), (2) projected_exhaustion_hours is calculated correctly from the current budget and burn rate, and (3) escalation_triggered is a boolean that aligns with your organization's burn rate thresholds. If validation fails, log the raw output and schema errors, then retry once with a repair prompt that includes the specific validation failure messages. Do not silently accept malformed risk classifications.

Model choice and temperature: Use a model with strong arithmetic reasoning for this task. Set temperature=0 to minimize variance in burn rate calculations and projections. The prompt includes a [RISK_LEVEL] constraint that should map to your internal severity definitions (e.g., critical when the budget will exhaust within 1 hour, warning when within 24 hours). The harness should compare the model's risk_level output against a deterministic threshold check as a secondary validation gate—if the model says low but your threshold math says critical, escalate the discrepancy for human review rather than trusting either source blindly.

Escalation wiring: When escalation_triggered is true, the harness must route the full verification payload—including the prompt snapshot, model output, and validation results—to your incident management system (e.g., PagerDuty, Opsgenie) with a structured alert. The alert should include the escalation_reason, projected_exhaustion_time, and a link to the relevant SLO dashboard. For high-severity classifications, require a human to acknowledge the alert before any automated rollback or remediation proceeds. This creates a clean audit trail linking the change event, the burn rate analysis, and the human approval decision.

Logging and audit: Persist every invocation as an immutable record: the input context, the raw model response, the validation results, and the escalation decision. This is critical for post-incident review and for demonstrating SLO governance to auditors. The harness should also track the evaluation_criteria from the prompt's companion eval block—specifically, whether the SLO window math was correct and whether the escalation trigger matched the defined policy. Run these evals asynchronously after each invocation and feed failures back into your prompt improvement cycle.