Incident Response Handoff Prompt for On-Call Engineers

This prompt is designed for SRE and DevOps teams that use AI agents to detect, triage, or investigate production incidents. When the AI reaches the limit of its safe operating boundary—whether due to low confidence, an unfamiliar failure mode, or a runbook step requiring human judgment—it must hand off to a human on-call engineer. This prompt produces a structured handoff payload containing severity classification, blast radius estimate, affected services, a timeline of events, diagnostic data, and the runbook step reached. Use this prompt inside an incident management pipeline where the AI has access to monitoring data, alert context, and runbook definitions.

The ideal user is an on-call engineer receiving a pre-triaged incident from an AI agent. The required context includes real-time alert payloads, recent deployment events, infrastructure metrics, and the specific runbook the AI was following. The prompt is not a general-purpose summarizer. Do not use it for customer-facing support handoffs, non-incident operational tasks, or situations where the AI has not already attempted diagnosis. The output is a machine-readable JSON payload designed for ingestion into PagerDuty, Opsgenie, or a custom incident management API. It must include a handoff_reason code from a defined taxonomy (e.g., CONFIDENCE_THRESHOLD, RUNBOOK_STEP_REQUIRES_HUMAN, UNKNOWN_FAILURE_MODE) so that routing rules can prioritize the page correctly.

Before deploying this prompt, ensure your AI agent's runbook definitions are explicit about which steps require human approval. A common failure mode is the AI handing off too early for trivial decisions or too late after making an unreviewed change. Implement a pre-handoff validation check that confirms the payload contains all required fields (severity, blast_radius_services, timeline, diagnostic_data, runbook_step_reached) and that the handoff_reason is not null. If validation fails, the system should retry the prompt once with a specific error message before escalating to a static fallback page. Always log the full handoff payload for post-incident review and prompt improvement.

This prompt template is designed to be integrated into your incident management harness. It takes structured incident data from your monitoring stack and produces a comprehensive handoff payload for an on-call engineer. The template uses square-bracket placeholders for all dynamic inputs, ensuring a clean separation between the prompt's logic and the data injected at runtime. Before using this in production, you must validate that your monitoring system can populate every required placeholder with accurate, real-time data.

codeCopy
You are an AI incident response handoff assistant for an SRE team. Your task is to synthesize the provided incident data into a structured, actionable handoff for the on-call engineer. Do not perform any diagnostic actions or make tool calls. Your only output is the handoff report.

## INCIDENT DATA
- Incident ID: [INCIDENT_ID]
- Alert Name: [ALERT_NAME]
- Trigger Timestamp: [TRIGGER_TIMESTAMP]
- Current Severity: [SEVERITY]
- Affected Services: [AFFECTED_SERVICES]
- Blast Radius Estimate: [BLAST_RADIUS]
- Timeline of Events: [EVENT_TIMELINE]
- Runbook Reference: [RUNBOOK_URL]
- Last Completed Runbook Step: [LAST_STEP_COMPLETED]
- Diagnostic Data: [DIAGNOSTIC_DATA]
- Related Recent Changes: [RECENT_CHANGES]

## OUTPUT INSTRUCTIONS
Generate a handoff report with the following sections. Be concise and factual. If a piece of data is missing or unknown, explicitly state that instead of guessing.

1.  **Executive Summary:** A 2-3 sentence overview of the incident, its current impact, and the most likely hypothesis.
2.  **Severity and Impact Assessment:** Confirm the current severity classification and justify it based on the blast radius and affected services.
3.  **Timeline of Events:** Present the [EVENT_TIMELINE] in a clear, chronological format.
4.  **Diagnostic Snapshot:** Summarize the key findings from the [DIAGNOSTIC_DATA]. Highlight anomalies and critical error messages.
5.  **Runbook Progress:** State the runbook being followed ([RUNBOOK_URL]), the last completed step ([LAST_STEP_COMPLETED]), and the immediate next step for the on-call engineer.
6.  **Recommended Immediate Actions:** Based on the diagnostic data and runbook progress, list 1-3 concrete, prioritized actions for the responder.
7.  **Context and Recent Changes:** Note any [RECENT_CHANGES] that could be related to the incident.

## CONSTRAINTS
- Do not fabricate diagnostic data or event details.
- If the severity is 'Critical' or 'High', prepend the report with '**URGENT: HUMAN ACTION REQUIRED**'.
- The output must be in plain text or Markdown, suitable for pasting into PagerDuty or Slack.

To adapt this template, start by mapping the placeholders to the exact fields in your monitoring and alerting tools (e.g., Datadog, Prometheus Alertmanager, PagerDuty). The [DIAGNOSTIC_DATA] placeholder is the most critical; it should contain a pre-formatted string of logs, error rates, and metric graphs, as the model cannot query these systems directly. For high-severity incidents, always pair this prompt with a programmatic guard that requires a human acknowledgment of the generated handoff before any automated remediation steps are executed. After generating the handoff, log the full prompt and completion for post-incident review and prompt evaluation.

This prompt is designed to be the final step in an AI-driven incident detection pipeline, not a standalone chatbot. It should be invoked only after the AI system has completed its diagnostic run—collecting logs, metrics, and runbook state—and determined that human intervention is required. The application layer is responsible for assembling the [INCIDENT_DATA], [DIAGNOSTIC_CONTEXT], [RUNBOOK_STATE], and [SEVERITY_CLASSIFICATION] placeholders from structured internal sources before calling the model. Do not pass raw, unprocessed log streams directly into this prompt; pre-process them into the expected input schema to keep the model focused on synthesis and handoff quality rather than log parsing.

Wire this prompt into your incident management workflow as a post-detection hook. When your monitoring system triggers an alert and the AI agent reaches its safe operating limit, call the model with the assembled context. The application must validate the model's JSON output against a strict schema before delivering it to the on-call engineer. Implement a retry loop with a maximum of two attempts if validation fails, using the validation error message as feedback in the retry prompt. If the model still fails to produce valid JSON after two retries, fall back to a pre-formatted template that includes the raw input data and a warning that the AI-generated summary is unavailable. Log every handoff attempt—including the prompt version, model version, input context hash, output, and validation result—for post-incident review and prompt debugging. For high-severity incidents (Sev0/Sev1), the handoff payload should also trigger an immediate push notification or page to the on-call engineer, bypassing any queue-based delivery.

Model choice matters here. Use a model with strong instruction-following and JSON mode capabilities, such as Claude 3.5 Sonnet or GPT-4o, and enable structured output mode if available. Set the temperature low (0.1–0.2) to maximize consistency in severity classification and action item generation. The handoff payload should be delivered to the on-call engineer through your existing incident channel—PagerDuty, Opsgenie, Slack, or a custom dashboard—with the AI-generated summary displayed prominently alongside links to raw diagnostic data. Never allow the AI to directly execute remediation actions from this prompt; the handoff is a read-only context transfer. The human operator must explicitly acknowledge the handoff and assume control before any further automated steps are taken. Finally, schedule a periodic review of handoff logs to identify patterns where the AI consistently misclassifies severity or misses critical context, and use those findings to improve both the prompt template and the upstream data assembly logic.