Rollback Trigger Evaluation Prompt

This prompt is for on-call engineers and SRE teams who need to evaluate whether active deployment symptoms meet rollback thresholds. It ingests observed metrics (error rates, latency, SLO burn), predefined threshold criteria, and deployment context, then produces a structured recommendation: rollback, continue with monitoring, or escalate for human investigation. Use this prompt during the first 5-15 minutes of a deployment when monitoring alerts fire and a decision must be made before the incident widens.

The prompt is a decision-support tool that forces structured reasoning under pressure. It does not replace your incident management tooling or on-call judgment. To use it effectively, you must provide concrete, timestamped metric values, your team's specific rollback thresholds, and the deployment's scope. The output is a clear recommendation with a confidence level and a chain of evidence, which you can then validate and act upon. The prompt's value lies in preventing the common failure mode of an on-call engineer making a gut-feel decision without systematically comparing the current state against pre-agreed criteria.

Do not use this prompt for pre-release risk assessment, post-incident root cause analysis, or situations where metric data is incomplete or stale. It is designed for a live, active deployment where symptoms are observable. If you are evaluating a release candidate before deployment, use the 'Release Readiness Assessment Prompt Template' instead. If the incident is already resolved and you are investigating what happened, use the 'Incident Root Cause Analysis Prompts'. Using this prompt with bad data will produce a confident but incorrect recommendation, which is worse than no recommendation at all.

This prompt is designed for on-call engineers and SRE teams who need to make a fast, evidence-based rollback decision during an active deployment. It ingests observed telemetry—error rates, latency spikes, and SLO burn—and compares them against predefined thresholds to recommend one of three actions: rollback, continue with monitoring, or investigate further. The prompt is structured to minimize hallucination by requiring explicit comparison of observed values against criteria and by demanding a confidence rating with supporting evidence.

textCopy
You are an on-call SRE assistant evaluating whether an active deployment should be rolled back. Your analysis must be grounded in the provided telemetry and thresholds. Do not invent data or assume values not present in the input.

## INPUT
Deployment ID: [DEPLOYMENT_ID]
Service: [SERVICE_NAME]
Observation Window: [START_TIME] to [END_TIME]

### Observed Telemetry
- Error Rate: [OBSERVED_ERROR_RATE]% (baseline: [BASELINE_ERROR_RATE]%)
- P99 Latency: [OBSERVED_P99_LATENCY]ms (baseline: [BASELINE_P99_LATENCY]ms)
- SLO Burn Rate: [OBSERVED_BURN_RATE]x (threshold: [BURN_RATE_THRESHOLD]x)
- Additional Signals: [ADDITIONAL_SIGNALS]

### Rollback Criteria
- Error rate exceeds [ERROR_RATE_THRESHOLD]% above baseline
- P99 latency exceeds [LATENCY_THRESHOLD]ms above baseline
- SLO burn rate exceeds [BURN_RATE_THRESHOLD]x
- Any critical user journey returning [CRITICAL_FAILURE_RATE]% errors

## OUTPUT_SCHEMA
Return a JSON object with the following fields:
{
  "recommendation": "rollback" | "continue" | "investigate",
  "confidence": 0.0-1.0,
  "triggered_criteria": ["list of criteria that were met"],
  "evidence_summary": "concise summary of observed vs threshold values",
  "risk_of_continuing": "low" | "medium" | "high" | "critical",
  "alternative_actions": ["list of options if rollback is not chosen"],
  "escalation_recommended": true | false
}

## CONSTRAINTS
- If no criteria are met, recommendation must be "continue"
- If any criterion is met, recommendation must be "rollback" or "investigate"
- Confidence must reflect how clearly the data supports the recommendation
- Do not recommend rollback solely on a single borderline metric without noting uncertainty
- If multiple criteria are met, risk_of_continuing must be "high" or "critical"
- Flag any missing telemetry that would improve the decision

To adapt this prompt for your environment, replace the square-bracket placeholders with values from your monitoring stack before execution. The rollback criteria section should mirror your team's actual SLO thresholds and error budgets. If your deployment pipeline provides additional signals—such as canary-vs-control comparisons, feature flag status, or dependency health—add them to the additional_signals field. The output schema is designed to be machine-readable for automated release gates, but the evidence_summary field also provides a human-readable justification for incident logs. Before putting this into production, test it against historical incidents where you know the correct decision to calibrate the confidence scoring and catch false-positive or false-negative patterns.

The Rollback Trigger Evaluation Prompt is designed to operate as a decision-support node inside an active incident response pipeline, not as a standalone chatbot. It should be invoked automatically when monitoring systems detect a threshold breach—such as a sustained error rate spike, a latency SLO burn rate exceeding a critical level, or a canary-versus-baseline divergence—and must receive a structured [INPUT] payload containing the observed metrics, the predefined rollback criteria, the deployment event timeline, and the current SLO budget status. The prompt's output is a structured recommendation (ROLLBACK, INVESTIGATE, or CONTINUE) with supporting evidence, which the surrounding harness must validate before surfacing to the on-call engineer or the automated release controller.

Wire the prompt into an incident automation workflow (e.g., a webhook receiver from your monitoring platform, a PagerDuty incident trigger, or a CI/CD pipeline stage). The harness should perform the following steps in order: (1) Input assembly—collect the required fields from your observability stack (Datadog, Prometheus, Honeycomb), your deployment tracker, and your SLO dashboard, and pack them into the [INPUT] schema. (2) Invocation—call the model with the prompt template, using a low-temperature setting (0.1–0.2) to prioritize consistency over creativity. (3) Output validation—parse the JSON response and validate that the recommendation field is one of the allowed enum values, that every evidence item references a specific metric or event from the input, and that the confidence score is a number between 0 and 1. Reject and retry once if validation fails; if it fails twice, escalate to a human with the raw model output and the validation errors. (4) Threshold gating—if the recommendation is ROLLBACK and the confidence is above 0.8, the harness may automatically trigger a rollback pipeline (with a mandatory notification to the incident commander). If the recommendation is ROLLBACK but confidence is below 0.8, or if the recommendation is INVESTIGATE, route the full evaluation payload to the on-call engineer for a manual decision. If the recommendation is CONTINUE, log the evaluation for audit and close the automated check. (5) Audit logging—record the full input, output, model version, timestamp, and the human decision (if any) in an immutable audit trail for post-incident review.

The highest-risk failure mode in this harness is a false-negative rollback decision—where the model recommends CONTINUE or INVESTIGATE while the system is actually degrading toward an outage. To mitigate this, implement a parallel safety check: independently calculate the SLO burn rate and error budget remaining from the raw metrics, and if the burn rate exceeds a hardcoded emergency threshold (e.g., the budget will be exhausted within 15 minutes), override the model's recommendation and force a ROLLBACK with a human-in-the-loop confirmation. Conversely, guard against false-positive rollbacks by requiring that any automated rollback action includes a cooldown period (e.g., no more than one automated rollback per 30-minute window) and a mandatory post-rollback validation that the rollback actually resolved the symptom before the incident is closed. Do not use this prompt for low-severity events or non-production environments where the cost of an unnecessary rollback outweighs the benefit of automated decision support. The prompt is a decision accelerator, not a replacement for runbook judgment, and every automated action path must leave a clear audit trail showing who (or what) made the call and on what evidence.