Error Budget Burn Rate Alert Prompt Template

This prompt is designed for AI Site Reliability Engineers (SREs) and platform operators who need to translate raw production trace data into actionable burn rate alerts. The core job-to-be-done is calculating how fast your AI system is consuming its error budget against a defined Service Level Objective (SLO) and predicting the time until that budget is exhausted. You should use this prompt when you have a configured SLO target (e.g., 99.9% of requests must return a valid, grounded response within 2 seconds), a defined evaluation window, and a stream of structured trace evaluations indicating pass/fail compliance. The primary output is a structured alert payload containing the current burn rate, a time-to-exhaustion projection, and a severity classification that can directly trigger an incident response pipeline.

Do not use this prompt for ad-hoc trace debugging or single-session root-cause analysis; it is designed for aggregate, threshold-based monitoring. It is also inappropriate if you lack a clear SLO definition or if your trace data does not include a binary compliance label. The prompt assumes you have already instrumented your application to tag spans with SLO-relevant outcomes. Required inputs include the [SLO_TARGET] (e.g., 99.5%), the [EVALUATION_WINDOW] (e.g., 30 days), the [ALERT_WINDOW] (e.g., 1 hour), and a [TRACE_EVALUATION_BATCH] containing timestamps and pass/fail results. Without these, the model will not be able to calculate a meaningful burn rate or severity level.

Before relying on this prompt in production, you must validate its arithmetic against a known baseline. A common failure mode is a mismatch between the alert window and the evaluation window, leading to a division-by-zero error or a falsely infinite time-to-exhaustion. You should also configure a human review step for any 'critical' severity alert before it pages an on-call engineer, as a sudden spike in synthetic traffic or a misconfigured eval pipeline can trigger a false positive. After reading this section, proceed to the prompt template to copy the exact instructions, and then review the implementation harness to understand how to wire the output into your monitoring stack.

This prompt template is designed to be wired into an AI operations pipeline that consumes structured trace data. It instructs the model to act as an AI SRE, calculating the rate at which an error budget is being consumed and classifying the severity of the burn. The output is a structured alert payload, not a conversational summary, making it suitable for direct ingestion by incident management systems like PagerDuty or Opsgenie.

textCopy
You are an AI SRE analyzing production trace data to evaluate error budget consumption.

Your task is to calculate the error budget burn rate, predict time-to-exhaustion, and generate a structured alert if thresholds are breached.

**Input Data:**
[TRACE_DATA]

**Configuration:**
- SLO Target: [SLO_TARGET] (e.g., 99.9%)
- Evaluation Window: [EVALUATION_WINDOW] (e.g., 1h, 30m)
- Alert Thresholds:
  - High Severity: [HIGH_SEVERITY_THRESHOLD] (e.g., burn rate > 10x)
  - Medium Severity: [MEDIUM_SEVERITY_THRESHOLD] (e.g., burn rate > 5x)
  - Low Severity: [LOW_SEVERITY_THRESHOLD] (e.g., burn rate > 2x)
- Incident Response Policy: [INCIDENT_RESPONSE_POLICY]

**Output Schema:**
You must produce a JSON object conforming to the following structure. Do not include any text outside the JSON.
{
  "alert_fired": boolean,
  "severity": "high" | "medium" | "low" | "none",
  "burn_rate_multiplier": number,
  "error_budget_consumed_percent": number,
  "time_to_exhaustion_minutes": number | null,
  "evaluation_window": string,
  "breaching_spans": [
    {
      "span_id": string,
      "error_type": string,
      "timestamp": string
    }
  ],
  "summary": string,
  "recommended_action": string
}

**Constraints:**
- Calculate the burn rate as the ratio of the current error rate to the error budget rate.
- If the error budget is not being consumed (0 errors), set `time_to_exhaustion_minutes` to `null` and `alert_fired` to `false`.
- The `summary` must be a concise, human-readable explanation of the situation, referencing the SLO target and the evaluation window.
- The `recommended_action` must be a single, clear step aligned with the [INCIDENT_RESPONSE_POLICY], such as "Page on-call" or "Create a low-priority ticket."
- Only include spans in `breaching_spans` that directly contributed to the error budget consumption.

To adapt this template, replace the square-bracket placeholders with data from your observability pipeline. [TRACE_DATA] should be a pre-processed, structured summary of relevant spans, not a raw dump of millions of lines. The alert thresholds should be tuned to your team's specific error budget policy and acceptable false-positive rate. Before deploying, run this prompt against a golden dataset of known trace patterns to validate that the burn rate calculation and severity classification match your expected outcomes.

This prompt is designed to be called by an automated monitoring service, not a human chat interface. The implementation harness should invoke the model on a fixed schedule (e.g., every 5 minutes) using the latest trace data aggregated from your observability backend. The [SLO_TARGET] and [EVALUATION_WINDOW] variables must be injected from a configuration store, not hardcoded, so that threshold changes do not require prompt edits. The [TRACE_DATA] input should be a pre-aggregated JSON payload containing error counts, total request counts, and timestamped buckets for the evaluation window. Do not pass raw trace spans directly; pre-process them into the expected input schema to keep the prompt focused on burn rate calculation rather than data cleaning.

The output must be validated against a strict JSON schema before any alert is triggered. Use a post-processing validator to confirm that burn_rate, error_budget_consumed_percent, and time_to_exhaustion_hours are present and within reasonable numeric ranges. If the model returns malformed JSON or missing fields, retry once with a repair prompt that includes the raw output and the expected schema. If the retry also fails, log the failure and escalate to the on-call engineer without generating an alert. For model choice, use a low-latency model with strong JSON mode support (e.g., GPT-4o or Claude 3.5 Sonnet) and set temperature=0 to maximize output determinism. Log every invocation—including the input trace summary, the raw model output, the validated result, and the alerting decision—to your observability platform for auditability and threshold tuning.

When the validated output indicates a severity of 'critical' or 'high', the harness should route the alert to your incident management system (e.g., PagerDuty, Opsgenie) with the alert_summary as the incident title and the full structured output as the incident body. For 'medium' severity, create a ticket in your tracking system. For 'low' or 'none', log the result silently. Avoid wiring this prompt directly to an alerting channel without the validation and severity routing layer; a hallucinated burn rate of 900% should never page an engineer. The harness should also track the false-positive rate of generated alerts against actual incidents to feed back into the [ALERT_THRESHOLD_TUNING] process described in the sibling playbook.