SLO Burn Rate and Release Decision Prompt

This prompt is designed for Site Reliability Engineers (SREs) and release managers who need to make a data-driven decision about whether to proceed with a production deployment based on current Service Level Objective (SLO) error budget consumption. The core job-to-be-done is to transform raw SLO telemetry—specifically the burn rate of the error budget over a recent time window—into a concrete, evidence-backed recommendation: proceed, hold, or escalate for an emergency budget review. The prompt does not replace human judgment for high-risk releases; it structures the calculation and projection so the human operator can audit the reasoning and make the final call under time pressure.

Use this prompt when you have a defined SLO target, a known error budget, and a measured burn rate from a monitoring system. The prompt requires structured inputs: the SLO target percentage, the compliance period, the current error budget remaining, the observed burn rate over a recent window, and the projected additional risk from the pending deployment. It is most effective when integrated into a release gate where these metrics are automatically fetched and injected into the prompt template. Do not use this prompt when the SLO is undefined, the error budget is not instrumented, or the burn rate data is stale—garbage-in, garbage-out applies with full force. It is also inappropriate for subjective release decisions based on feature completeness, stakeholder pressure, or marketing timelines; this prompt is strictly for SLO-based risk evaluation.

The prompt produces a structured recommendation with a confidence level, a budget exhaustion projection, and a list of conditions that would change the recommendation. It includes explicit handling for edge cases: when the burn rate is zero but the deployment introduces new risk, when the remaining budget is below the review threshold, and when the projection window extends beyond the compliance period. After using this prompt, you should log the output as part of your release decision audit trail and, if the recommendation is 'hold' or 'emergency review,' route the decision to the appropriate escalation path with the prompt's evidence attached. Never treat the model's output as an automated gate without human review when the remaining error budget is below 50% or the projected impact could exhaust the budget within the current compliance window.

This prompt template is designed to be dropped into an SRE workflow where a release decision must account for current error budget consumption. It expects structured inputs—current SLO status, recent error rates, deployment risk profile, and organizational thresholds—and produces a recommendation with supporting calculations. The template uses square-bracket placeholders so you can wire it directly into an automation harness that populates these fields from your observability stack and deployment pipeline before sending the prompt to the model.

textCopy
You are an SRE release decision assistant. Your task is to evaluate whether current error budget consumption allows a proposed release to proceed.

## INPUTS
- Current SLO target: [SLO_TARGET_PERCENT]
- Current compliance period remaining: [PERIOD_REMAINING_HOURS]
- Error budget remaining (absolute): [ERROR_BUDGET_REMAINING]
- Current burn rate (errors per hour, trailing 1h): [BURN_RATE_1H]
- Current burn rate (errors per hour, trailing 6h): [BURN_RATE_6H]
- Deployment risk profile: [DEPLOYMENT_RISK_PROFILE]
  - Expected blast radius (users affected): [BLAST_RADIUS_USERS]
  - Historical failure rate for similar deployments: [HISTORICAL_FAILURE_RATE]
  - Estimated error injection if deployment fails: [ESTIMATED_ERROR_INJECTION]
- Organizational thresholds:
  - Burn rate alert threshold (x baseline): [BURN_RATE_ALERT_MULTIPLIER]
  - Emergency budget review threshold (% remaining): [EMERGENCY_REVIEW_PCT]
  - Release hold threshold (% remaining): [RELEASE_HOLD_PCT]

## OUTPUT_SCHEMA
Return a JSON object with these fields:
{
  "recommendation": "PROCEED" | "HOLD" | "EMERGENCY_REVIEW",
  "confidence": 0.0-1.0,
  "burn_rate_assessment": {
    "current_multiple_of_baseline": number,
    "exceeds_alert_threshold": boolean,
    "projected_budget_exhaustion_hours": number | null,
    "trend": "INCREASING" | "STABLE" | "DECREASING"
  },
  "budget_assessment": {
    "remaining_percent": number,
    "below_hold_threshold": boolean,
    "below_emergency_threshold": boolean
  },
  "deployment_risk_assessment": {
    "worst_case_budget_consumption": number,
    "would_exhaust_budget": boolean,
    "risk_level": "LOW" | "MEDIUM" | "HIGH" | "CRITICAL"
  },
  "rationale": "string explaining the recommendation with specific numbers",
  "conditions": ["list of conditions that would change the recommendation"],
  "monitoring_requirements": ["list of metrics to watch if PROCEED"]
}

## CONSTRAINTS
- Base all calculations on the provided inputs. Do not assume defaults.
- If burn rate exceeds the alert threshold, the recommendation must be HOLD or EMERGENCY_REVIEW unless the deployment risk profile shows zero expected error injection.
- If remaining error budget is below the emergency review threshold, the recommendation must be EMERGENCY_REVIEW regardless of other signals.
- If remaining error budget is below the hold threshold but above the emergency threshold, PROCEED is only allowed when burn rate is DECREASING and deployment risk is LOW.
- Projected budget exhaustion must be calculated as: ERROR_BUDGET_REMAINING / BURN_RATE_1H, using the 1h burn rate. If burn rate is zero, return null.
- Worst-case budget consumption must be calculated as: ESTIMATED_ERROR_INJECTION * (1 + HISTORICAL_FAILURE_RATE).
- Confidence must reflect data completeness and signal alignment. Reduce confidence when burn rate trends conflict (1h vs 6h) or when deployment risk is HIGH but budget is ample.
- Do not recommend PROCEED without listing specific monitoring requirements.

## EXAMPLES
[EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

To adapt this template, replace each bracketed placeholder with values from your observability platform and deployment pipeline. The [EXAMPLES] placeholder should contain 2-3 few-shot examples showing correct calculations for different scenarios—one where budget is healthy and burn rate is low (PROCEED), one where burn rate exceeds threshold (HOLD), and one where budget is critically low (EMERGENCY_REVIEW). The [RISK_LEVEL] placeholder should contain your organization's risk tolerance statement, such as 'Conservative: prefer HOLD when signals conflict' or 'Standard: allow PROCEED when budget is above hold threshold and burn rate is stable.' Wire this prompt into a harness that validates the output JSON against the schema before surfacing the recommendation. For high-risk deployments where DEPLOYMENT_RISK_PROFILE.risk_level would be CRITICAL, require human approval regardless of the model's recommendation.

This prompt is designed to sit inside a release gate service or CI/CD pipeline stage that executes before a deployment proceeds. The application layer is responsible for fetching the raw SLO data—current error budget remaining, burn rate over the evaluation window, and projected impact of the deployment—and injecting it into the prompt's [SLO_METRICS] and [DEPLOYMENT_CONTEXT] placeholders. The model should never be given direct query access to your observability backend; instead, the harness pre-computes the burn rate and remaining budget from your metrics store (e.g., Prometheus, Datadog, Cloud Monitoring) and passes only the structured summary to the prompt. This separation ensures the model reasons over prepared data rather than attempting arithmetic on raw time series, which is a common source of hallucination.

The harness must validate the model's output against a strict schema before the recommendation is surfaced. Define a JSON schema that requires: recommendation (enum: PROCEED, HOLD, EMERGENCY_REVIEW), burn_rate_multiplier (float), budget_exhaustion_estimate_hours (float or null), confidence (enum: HIGH, MEDIUM, LOW), and evidence (array of strings). After receiving the model response, validate it against this schema. If validation fails, retry once with the error message appended to the prompt as a correction hint. If the retry also fails, escalate to a human release manager via your incident management tool (e.g., PagerDuty, Opsgenie) and log the failure for prompt debugging. For EMERGENCY_REVIEW recommendations, the harness should automatically create a ticket or page the on-call SRE; do not let the pipeline silently proceed.

Model choice matters here. Use a model with strong structured output support and low latency, since release gates are time-sensitive. GPT-4o or Claude 3.5 Sonnet with structured outputs mode enabled are good defaults. Set temperature=0 to maximize consistency on the numeric reasoning. Implement a circuit breaker: if the prompt call exceeds 10 seconds, time out and fall back to a conservative HOLD recommendation with a note that the automated check was unavailable. Log every invocation—input metrics, model response, validation result, and final recommendation—to your audit store. This audit trail is critical for post-incident review and for calibrating the prompt's accuracy against actual deployment outcomes. Avoid wiring this prompt directly into an auto-approval path; the recommendation should always be a signal into a human decision or a higher-level automated gate that considers multiple signals, not a single-prompt bypass.