Postmortem Timeline Reconstruction Prompt

This prompt is built for incident analysts and SREs who need to construct a blameless postmortem timeline from fragmented operational data after an incident is resolved. The core job-to-be-done is transforming a messy collection of monitoring alerts, deployment events, chat transcripts, and human action records into a single, causally-linked, and review-ready artifact. The ideal user has already completed the incident response and gathered all relevant raw event streams; they are now entering the post-hoc analysis phase and need a structured narrative, not a real-time dashboard.

You should use this prompt when you have a complete or near-complete dataset from the incident window and need to identify the sequence of events, detection-to-resolution markers, and contributing factors. The prompt assumes you can provide data sources like PagerDuty alerts, CI/CD deploy logs, Slack threads, and runbook execution timestamps. It is not designed for real-time incident command, where an on-call engineer needs to query live metrics or execute remediation steps. Do not use this prompt if your primary goal is to assign blame, as the instructions are explicitly tuned for blameless analysis and causal reasoning.

Before executing this prompt, verify that you have sanitized any sensitive data from chat logs and that timestamps across different systems are normalized to a single timezone. The output is a structured timeline meant for human review and collaborative editing, not a final, publish-ready document. If the incident involves ongoing legal review or external regulatory reporting, the generated timeline must be treated as a draft and reviewed by legal or compliance teams before any external distribution.

This prompt template instructs the model to act as an incident analyst and produce a structured, blameless postmortem timeline. It is designed to synthesize heterogeneous inputs—monitoring alerts, deployment events, chat transcripts, and human action logs—into a single, causally-linked narrative. The output is a strict JSON schema suitable for direct ingestion into incident management tools or postmortem documentation systems.

textCopy
SYSTEM: You are an incident analyst constructing a blameless postmortem timeline. Your goal is to synthesize the provided data into a unified, causally-linked sequence of events from initial detection to final resolution. Focus on factual accuracy and avoid assigning blame to individuals. If the provided data is insufficient to establish a causal link, mark the relationship as 'correlated' rather than 'caused_by'.

USER:
Reconstruct a postmortem timeline using the following inputs.

[INCIDENT_NAME]

MONITORING ALERTS:
[ALERTS_JSON]

DEPLOYMENT EVENTS:
[DEPLOYMENTS_JSON]

CHAT LOGS:
[CHAT_TRANSCRIPT_TEXT]

HUMAN ACTIONS:
[MANUAL_ACTIONS_LOG]

[OUTPUT_SCHEMA]
{
  "incident_name": "string",
  "detection_time": "ISO 8601 timestamp",
  "resolution_time": "ISO 8601 timestamp",
  "timeline": [
    {
      "timestamp": "ISO 8601 timestamp",
      "event_type": "DETECTION | DEPLOYMENT | ACTION | ESCALATION | MITIGATION | RESOLUTION",
      "description": "A concise, factual description of the event.",
      "source": "Reference to the specific input log or alert ID.",
      "causal_relationship_to_next": "caused_by | correlated | resolved_by | null"
    }
  ],
  "contributing_factors": ["string"],
  "detection_gap_seconds": "integer"
}

[CONSTRAINTS]
- The timeline must be sorted chronologically.
- Every event in the timeline must cite a source from the provided inputs.
- If a causal link is speculative, use 'correlated' and note the uncertainty in the contributing_factors array.
- The detection_gap_seconds is the difference between the earliest known symptom timestamp and the detection_time.

To adapt this template, replace the square-bracket placeholders with your actual incident data. The [OUTPUT_SCHEMA] is provided inline as a JSON schema for the model to follow; you can move this to a structured output API parameter if your platform supports it. For high-severity incidents, always include a human review step before the generated timeline is published. Validate the output against the schema programmatically, and if the model fails to cite sources for key events, re-prompt with a specific instruction to ground each claim in the provided logs.

This prompt is designed to be the core reasoning step in a larger postmortem generation pipeline. It should not be called in isolation. The application layer must first gather and normalize all required inputs—monitoring alerts, deployment events, chat transcripts, and change logs—before assembling them into the [INCIDENT_EVIDENCE] block. The model's output is a structured timeline, but the harness is responsible for validating that structure, linking back to source evidence, and presenting it for human review before the postmortem is finalized.

Wire the prompt into a multi-step workflow: (1) a data collection phase queries your observability platform, CI/CD pipeline, and communication tools for events within the incident window; (2) a normalization step converts timestamps to UTC, deduplicates overlapping alerts, and tags each event with a source identifier; (3) the prompt is called with the assembled evidence and a strict [OUTPUT_SCHEMA] specifying the timeline JSON structure; (4) the output is validated against that schema, checking that every timeline entry has a required timestamp, source reference, and event type; (5) a post-processing step links each entry back to its original evidence record for auditability. Use a model with strong structured output support, such as GPT-4o or Claude 3.5 Sonnet, with response_format set to json_schema where available. For high-severity incidents, route the generated timeline to a human incident commander for approval before it enters the postmortem document.

Common failure modes to guard against: the model may hallucinate causal links between events that are merely temporally correlated. Mitigate this by requiring the [CONSTRAINTS] field to enforce that causal relationships must be explicitly supported by evidence, not inferred from timing alone. The model may also omit human actions that were critical to resolution. Ensure your evidence collection includes chat logs and manual intervention records. Implement a retry loop with a validator that checks for required fields and rejects timelines with missing detection or resolution markers. Log every prompt invocation, the raw output, and the validation result for post-incident review and prompt improvement. Do not treat this prompt as a replacement for human postmortem analysis—it is a synthesis tool that accelerates the timeline construction step, but the final contributing factor identification and action items require human judgment.