Incident Timeline Extraction Prompt Template

This prompt is built for SRE and on-call engineering teams who need to reconstruct a single, coherent incident timeline from multiple unstructured sources. Use it when you have chat transcripts, monitoring alerts, and deployment records that describe the same incident window and you need a normalized, time-ordered event log. The primary job-to-be-done is post-hoc analysis: turning the chaotic, multi-source record of an incident into a structured chronology that can be used for postmortem drafting, contributing factor analysis, and remediation planning.

The ideal user is an engineer who has already gathered the raw text from each source and is ready to pass it to the model. The prompt assumes you are not feeding it live data streams or real-time monitoring output. It is not a replacement for a real-time monitoring system, a logging platform, or an observability tool. It is a post-incident analysis tool that works on a defined window of time after the incident has been declared over or stable. The required context includes the incident's start and end time, the raw text from each source, and any known constraints such as timezone or clock skew between systems.

Do not use this prompt when you need real-time alert correlation, when the raw data volume exceeds the model's context window without summarization, or when the sources contain conflicting timestamps that require deterministic reconciliation rather than probabilistic ordering. The prompt is also unsuitable for incidents where legal or regulatory requirements demand a fully auditable, human-authored timeline without AI intermediation. In those cases, use this output as a draft for human review, not as the final record. Before running the prompt, ensure you have stripped any sensitive PII or credentials from the source text that should not be passed to the model.

This template is designed to be pasted directly into your AI harness, whether that's a Python script, a LangChain node, or an internal tool. It accepts raw incident data—chat transcripts, monitoring alerts, deployment records—and produces a structured, time-ordered event log. The prompt enforces strict timestamp normalization, gap detection, and conflict flagging, making it suitable for post-incident review and postmortem drafting. Before running, replace every square-bracket placeholder with the actual values for your incident and organization.

textCopy
You are an SRE incident analyst. Your task is to extract a normalized, time-ordered timeline of events from the provided incident data.

## INPUT DATA
[INCIDENT_DATA]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "incident_id": "string",
  "generated_at": "ISO 8601 timestamp",
  "timeline": [
    {
      "timestamp": "ISO 8601 timestamp in UTC",
      "source": "string (e.g., 'slack_transcript', 'pagerduty_alert', 'datadog_monitor', 'deployment_log')",
      "event_type": "string (e.g., 'alert_fired', 'human_observation', 'deployment_started', 'mitigation_applied', 'resolution_confirmed')",
      "description": "string (concise, factual description of the event)",
      "actor": "string or null (the system or person who triggered the event)",
      "evidence": "string (verbatim quote or data point from the input that supports this event)",
      "confidence": "string (HIGH | MEDIUM | LOW)"
    }
  ],
  "gaps": [
    {
      "start": "ISO 8601 timestamp or null",
      "end": "ISO 8601 timestamp or null",
      "description": "string (what is missing, e.g., 'No data between alert fire and first human response')"
    }
  ],
  "conflicts": [
    {
      "event_ids": ["index of first conflicting event", "index of second conflicting event"],
      "description": "string (explanation of the contradiction, e.g., 'Deployment log shows rollback at 14:05, but Slack transcript claims rollback at 14:12')"
    }
  ]
}

## CONSTRAINTS
- All timestamps must be normalized to UTC ISO 8601 format (e.g., '2025-03-15T14:05:00Z').
- If a source provides a timestamp in a different timezone, convert it and note the original timestamp in the evidence field.
- Sort the timeline array strictly by timestamp ascending.
- If an event's exact timestamp is ambiguous, set the timestamp to the earliest possible time based on context, set confidence to LOW, and explain the ambiguity in the evidence field.
- Deduplicate events that appear in multiple sources. Merge them into a single event, list all sources, and keep the highest-confidence timestamp.
- Flag any period longer than [GAP_THRESHOLD_MINUTES] minutes without an event as a gap.
- Flag any direct contradiction between sources as a conflict.
- Do not infer events that are not explicitly supported by the input data. If the data is insufficient, record a gap.
- Do not assign blame or speculate on root cause. This is a fact-extraction task only.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, start by replacing [INCIDENT_DATA] with the raw text from your incident sources. This can be a concatenation of Slack transcripts, PagerDuty alert payloads, Datadog monitor snapshots, and deployment logs. The model will parse timestamps from these heterogeneous formats. Next, set [GAP_THRESHOLD_MINUTES] to a value appropriate for your incident response SLA—typically 5, 10, or 15 minutes. If you have high-quality examples of correctly extracted timelines from past incidents, insert them into [FEW_SHOT_EXAMPLES] as JSON objects matching the output schema. This significantly improves extraction accuracy, especially for event_type classification. Finally, set [RISK_LEVEL] to HIGH, MEDIUM, or LOW based on the incident's severity. For HIGH risk incidents, the generated timeline must be reviewed by a human incident commander before it is used in any postmortem or external communication. For LOW risk, the timeline can feed directly into automated postmortem drafting, but a human should still spot-check the gaps and conflicts arrays before finalization.

This prompt is designed to be called as part of a post-incident review pipeline, not as a real-time chat interaction. The primary input is a concatenated text blob containing chat transcripts (Slack, Teams, PagerDuty), monitoring alert payloads, and deployment event logs. Before calling the model, you must normalize timestamps to UTC and deduplicate overlapping sources at the application layer. The model's job is to produce a single, ordered JSON array of events—it should not be asked to resolve timezone offsets or deconflict raw source data. Expect to run this prompt once per incident, with the output feeding directly into a postmortem drafting tool or a timeline visualization dashboard.

Wire the prompt into an async job queue with a timeout of at least 60 seconds for large incident transcripts. Implement a validation layer that checks the output JSON against a strict schema: every event must have a non-null timestamp (ISO 8601), a source field matching one of the provided source identifiers, and a description string under 500 characters. Reject outputs with duplicate timestamps that lack distinct source attribution. If validation fails, retry once with the same input and an explicit error message appended to the prompt context indicating which validation rule was violated. After two failures, escalate to a human reviewer via your incident management tool and log the raw model output for debugging. For model choice, use a model with strong structured output capabilities and a context window large enough to hold your worst-case incident transcript plus the prompt template—typically 32K tokens minimum for multi-hour incidents.

Do not use this prompt for real-time incident response or live chat ingestion. The extraction is a post-hoc analysis step. If your incident involves regulated data (PII in chat logs, healthcare information, financial transaction details), you must redact sensitive fields before they reach the model and flag the output for human review before it enters any permanent record. Build an eval harness that tests the prompt against at least five historical incidents with known timelines, measuring timestamp recall (did we miss events?), ordering accuracy (are events in the correct sequence?), and hallucination rate (did the model invent events not present in the source material?). Run these evals whenever you change the prompt template, the model version, or the input normalization logic. The output of this prompt is evidence for root cause analysis, not the final answer—always treat it as a structured draft that requires SRE confirmation before it becomes the official incident record.