Configuration Drift Incident Postmortem Prompt

This prompt is designed for Site Reliability Engineers (SREs) and platform engineering teams who need to produce a blameless, structured postmortem after a confirmed configuration-drift incident. The core job-to-be-done is transforming raw forensic evidence—such as chat transcripts, monitoring alerts, Infrastructure-as-Code (IaC) diffs, and audit logs—into a coherent document that identifies the root cause, assesses customer impact, and defines actionable prevention items. It is not a real-time diagnostic tool; it assumes the incident is resolved and the system is stable.

To use this prompt effectively, you must provide a complete incident context. This includes a detailed timeline of events, relevant chat logs (e.g., Slack, PagerDuty transcripts), specific monitoring alerts that fired, and the exact IaC or configuration diffs that represent the drift. The prompt is engineered to correlate these inputs, distinguishing between a manual emergency fix that was never codified and a failure in an automated reconciliation loop. Do not use this prompt during an active incident when the root cause is still unknown or when the system is in a degraded state; it requires a post-resolution context to avoid hallucinating a timeline or misattributing cause. Similarly, avoid using it for simple, single-resource drifts that don't warrant a full postmortem process.

Before executing this prompt, validate that your input data is complete and redacted. Remove any secrets, PII, or sensitive credentials from chat logs and diffs before they enter the model's context window. The output is a structured markdown document, but it is a draft that requires human review. An SRE must verify the model's root cause analysis against their own understanding of the system and ensure that all proposed prevention items are practical and prioritized correctly. The next step after generation is to circulate this draft for stakeholder review, not to publish it directly.

This prompt template is designed to be pasted directly into your AI system. It enforces a structured output, evidence grounding, and a clear separation of facts from interpretation. Before execution, replace every square-bracket placeholder with data from your incident: the timeline, chat logs, monitoring alerts, and the specific systems affected. The prompt is built to produce a consistent postmortem that an SRE team can immediately review, rather than a generic summary that requires heavy editing.

textCopy
You are an SRE postmortem analyst. Your task is to generate a structured incident postmortem for a configuration-drift event.

You must ground every finding in the provided evidence. Do not invent details. If evidence is missing for a section, state 'Insufficient evidence provided' and explain what is needed.

[INCIDENT_SUMMARY]: A brief, factual description of the incident, including the service(s) affected, the duration of user impact, and the triggering detection method.

[TIMELINE]: A chronologically ordered list of events from the incident. Each event must include a timestamp, the actor or system, the action taken, and the observed effect. Source these from the provided chat logs and monitoring data.

[ROOT_CAUSE]: A detailed analysis of the root cause. Distinguish between the direct trigger (the specific configuration change) and any contributing factors (e.g., insufficient testing, lack of guardrails, manual intervention).

[IMPACT_ASSESSMENT]: Quantify the blast radius. Include the number of users affected, the duration of the outage or degradation (MTTD/MTTR), and any data loss, financial impact, or SLA breach.

[DETECTION_GAP_ANALYSIS]: Identify gaps in monitoring, alerting, and testing that allowed the drift to reach production or delayed its detection. Explain why existing checks failed to catch the change.

[PREVENTION_ITEMS]: A list of concrete, actionable, and trackable action items to prevent recurrence. Each item must have an owner and a proposed implementation approach. Categorize items as 'Immediate Fix', 'Process Change', or 'System Hardening'.

[OUTPUT_SCHEMA]:
{
  "incident_summary": "string",
  "timeline": [{"timestamp": "string", "actor": "string", "action": "string", "effect": "string"}],
  "root_cause": {"direct_trigger": "string", "contributing_factors": ["string"]},
  "impact_assessment": {"affected_users": "number", "duration_minutes": "number", "mttd_minutes": "number", "mttr_minutes": "number", "data_loss": "string", "sla_breach": "boolean"},
  "detection_gap_analysis": [{"gap": "string", "why_it_failed": "string"}],
  "prevention_items": [{"action": "string", "owner": "string", "category": "Immediate Fix | Process Change | System Hardening", "implementation_approach": "string"}]
}

[CONSTRAINTS]:
- Do not assign blame to individuals. Focus on systems and processes.
- Use precise timestamps (UTC) from the evidence.
- If a metric is unknown, use null, not a guess.
- The postmortem must be self-contained and understandable without external context.

[EVIDENCE]:
- Incident chat logs: [CHAT_LOG_TEXT]
- Monitoring alerts: [ALERT_LOG_TEXT]
- IaC change history: [IAC_DIFF_TEXT]
- Live state snapshot: [LIVE_STATE_TEXT]

To adapt this template for your own runbooks, replace the evidence placeholders with your actual data sources. For high-severity incidents, add a [HUMAN_REVIEW] step before the final postmortem is published. The structured [OUTPUT_SCHEMA] is critical for programmatic consumption; ensure your application harness validates the JSON against this schema and rejects malformed responses. For recurring use, wire this prompt into a system that automatically fetches chat logs and IaC diffs from your incident management and version control APIs.

This prompt is designed to be called after an incident closes, not during active triage. The harness must assemble a structured input payload from your incident management system (e.g., PagerDuty, FireHydrant, Jira) and chat transcripts (Slack, Teams). The prompt expects a timeline of events, a list of detected drift findings, and relevant chat logs. Do not pass raw, unprocessed logs—pre-process them into a chronological timeline with timestamps, actor identities, and actions taken. The model performs best when the input is already organized; it should not be asked to reconstruct a timeline from scattered fragments.

Implement a validation layer that checks the model's output against a strict JSON schema before the postmortem is accepted. Required fields include incident_id, timeline (array of events with timestamp, action, actor), root_cause (object with primary_cause and contributing_factors), impact (object with duration_minutes, affected_services), detection_gap (string), and prevention_items (array of strings). If the output fails schema validation, retry up to two times with a more explicit error message appended to the prompt. After two failures, route the raw output to a human reviewer in a draft queue rather than publishing an incomplete postmortem. Log every attempt, the validation errors, and the final disposition for auditability.

For model selection, use a model with strong structured output capabilities and a large context window (e.g., Claude 3 Opus or GPT-4 Turbo) because incident timelines and chat logs can be lengthy. Enable structured output mode if the provider supports it (e.g., JSON mode or function calling with a strict schema) to reduce post-generation repair. If your incident data contains sensitive information—PII in chat logs, internal IP addresses, or secret names—run a redaction step before the prompt assembly. The prompt template's [REDACTED_LOG] placeholder should receive sanitized text. Never pass raw secrets or customer data into the model context. Store the final approved postmortem in your incident knowledge base and link it back to the source incident for future reference and pattern analysis.