Postmortem Timeline Event Extraction Prompt

This prompt is designed for a specific post-incident workflow: converting a completed, human-written postmortem narrative into a structured, machine-parseable timeline. The ideal user is an incident analyst, SRE, or engineering manager who needs to extract a chronologically ordered array of event objects for pattern analysis, cross-incident comparison, or ingestion into an incident management platform. The required context is a finished narrative document that describes the incident lifecycle—detection, diagnosis, mitigation, and resolution—in free-text form. The prompt's value is in reliably structuring this narrative, not in interpreting raw telemetry.

Use this prompt when you have a static document and need a consistent output schema with fields like timestamp, action, impact, and responsible_party. It is built for offline batch processing, not for real-time alert triage or live incident response. The prompt assumes the input text contains a complete story; it will not fill in gaps from external systems. For example, a valid input is a postmortem document titled 'Payment Service Outage — 2024-11-15,' and the expected output is a JSON array where each event has a normalized ISO 8601 timestamp and a controlled-vocabulary event_type like detection, mitigation, or resolution.

Do not use this prompt for extracting events from raw log streams, chat transcripts, or live dashboards. It is not designed for real-time data and will hallucinate structure where only noise exists. Similarly, avoid using it for incident response playbooks where actions are still in progress; the narrative must be complete. If your input is a messy, multi-contributor document, pre-process it to consolidate the narrative before using this prompt. For live data extraction, use a log parsing pipeline. For real-time response, use a runbook automation prompt. This prompt is a post-hoc analysis tool, and using it outside that context will produce unreliable timelines.

This prompt template is designed to be dropped directly into your AI harness. It instructs the model to act as an incident analyst, extracting a chronologically ordered array of events from a provided postmortem document. The prompt uses square-bracket placeholders for all dynamic inputs, making it easy to parameterize in code. The core instruction forces the model to produce a valid JSON array, with each event object adhering to a strict schema that includes a normalized timestamp, an action, an impact, and a responsible party. This structured output can then be directly ingested by your observability or incident management platform without manual parsing.

textCopy
You are an expert incident analyst. Your task is to extract a structured, chronological timeline of events from the provided postmortem narrative.

INPUT POSTMORTEM:
[POSTMORTEM_NARRATIVE]

OUTPUT_SCHEMA:
Return a single JSON array of event objects. The array must be ordered chronologically by the `timestamp` field. Each event object must conform to this structure:
{
  "timestamp": "ISO 8601 string (e.g., 2023-10-27T14:30:00Z)",
  "action": "A concise, specific description of what happened (e.g., 'Deployed v2.3.1 to production', 'PagerDuty alert fired for high latency')",
  "impact": "The immediate observable consequence (e.g., 'Users in us-east-1 experienced 500 errors', 'On-call engineer acknowledged the page')",
  "responsible_party": "The person, team, or automated system that performed the action (e.g., 'Release Engineering', 'monitoring-system', 'Alice Smith')",
  "event_type": "One of: 'detection', 'diagnosis', 'mitigation', 'resolution', 'notification', 'other'"
}

CONSTRAINTS:
- Extract every discrete event from the narrative. Do not summarize or skip steps.
- If a timestamp is missing for an event, infer it from the surrounding context or set it to null. Do not guess.
- The `event_type` field must be one of the specified values.
- If the `responsible_party` is unclear, use "unknown".
- Output ONLY the valid JSON array. Do not include any text before or after the JSON.

To adapt this template, replace the [POSTMORTEM_NARRATIVE] placeholder with the full text of your incident report. You can tighten the event_type enum to match your organization's specific incident management taxonomy. For high-stakes postmortems, consider adding a [CONFIDENCE] field to the schema and instructing the model to flag low-confidence extractions for human review. The output of this prompt should be validated in your application layer to ensure it is a parseable JSON array and that every object contains all required fields before being written to a system of record.

This prompt is designed to be the first stage in an automated postmortem enrichment pipeline. It should be called immediately after an incident narrative is finalized, before the timeline is reviewed by a human. The prompt expects a single, complete narrative as [INPUT]. Do not stream partial narratives or concatenate chat logs without first normalizing them into a single document. The model should be configured with a low temperature (0.0–0.2) to maximize deterministic extraction, and you should request structured output using the JSON Schema defined in the prompt template to avoid parsing errors downstream.

Wire the prompt into your application with a validate-extract-review loop. After receiving the model response, run a validation step that checks: (1) every event has a non-null timestamp, action, and impact field; (2) the events array is sorted in ascending chronological order; (3) no two events share the same timestamp unless they have distinct source_system values; and (4) all responsible_team values match a controlled vocabulary from your service catalog. If validation fails, re-prompt the model with the validation errors appended to [CONSTRAINTS] and request a corrected output. Limit retries to two attempts. If validation still fails after two retries, flag the extraction for mandatory human review and log the raw narrative, the failed outputs, and the validation errors to your observability platform for later debugging.

For high-severity incidents (SEV1/SEV2), always route the extracted timeline to a human incident commander for approval before it is published to the postmortem document or shared with stakeholders. The approval step should display the extracted events in a diffable view against the original narrative, highlighting any inferred timestamps or actions the model synthesized rather than extracted verbatim. Store the final approved timeline as a versioned artifact in your incident management system, tagged with the model version, prompt version, and reviewer identity. Avoid using this prompt for real-time incident response during active mitigation; it is designed for post-resolution analysis where the full narrative is available and accuracy takes priority over speed.