Incident Timeline Structuring Demonstration Prompt

This prompt is designed for incident commanders and SRE teams who need to convert messy, multi-source incident data into a structured, causally-linked timeline. It teaches the model to extract events, normalize timestamps, infer causal relationships, and annotate impact through few-shot demonstrations rather than verbose procedural instructions. Use this when you have chat logs, monitoring alerts, and deployment records that must be assembled into a single chronological narrative for a postmortem or incident review.

This prompt assumes you have already collected and deduplicated the raw source material. It does not replace your incident management tooling; it structures the narrative evidence that feeds into it. The ideal input is a pre-assembled text blob containing all relevant logs, messages, and alerts. The output is a strictly ordered JSON timeline. Do not use this prompt for real-time alerting, as it is designed for post-hoc analysis. It is also unsuitable for generating action items or remediation steps; its sole job is evidence structuring.

Before using this prompt, ensure your raw data is complete. The model will not detect missing sources. If a critical Slack channel or monitoring stream is absent from the input, the resulting timeline will contain a narrative gap. Always pair this prompt with an evaluation step that checks for temporal ordering and missing event detection. If the timeline will be used in a customer-facing incident report, a human reviewer must verify the causal links the model infers.

This prompt template structures raw incident chatter and monitoring snippets into a rigorous timeline. It relies on few-shot examples to teach the model three specific skills: event extraction with timestamp normalization, causal linking between events, and impact annotation using a controlled vocabulary. The examples are the primary teaching mechanism—they show the exact output schema, the delimiter conventions, and the annotation rules before the model processes the target input. Adapt the placeholder values to match your incident taxonomy, timezone conventions, and severity definitions.

textCopy
You are an incident timeline structuring assistant. Your task is to convert raw incident chat logs and monitoring data into a structured timeline.

Follow these rules:
- Extract discrete events. Each event must have a normalized timestamp in ISO 8601 UTC.
- Link causally related events using the `caused_by` field, referencing the `event_id` of the preceding event.
- Annotate each event with an `impact` field from this controlled vocabulary: [SEVERITY_LEVELS].
- If a timestamp is ambiguous or missing, mark it as `null` and set `confidence` to `low`.
- Output ONLY a valid JSON object matching the [OUTPUT_SCHEMA]. Do not include any text outside the JSON.

[EXAMPLES]

Now, process the following input and produce the structured timeline:

[INPUT]

Adaptation guidance: Replace [SEVERITY_LEVELS] with your incident severity taxonomy as a JSON array of strings (e.g., ["critical", "major", "minor", "observational"]). Replace [OUTPUT_SCHEMA] with a concise JSON Schema definition of the expected output object, including required fields (event_id, timestamp, description, caused_by, impact, confidence). The [EXAMPLES] placeholder should contain 2–3 fully worked input-output pairs that demonstrate correct timestamp normalization, causal chain construction, and impact annotation. Each example must include the raw input block and the corresponding structured JSON output. The [INPUT] placeholder receives the target chat log or monitoring snippet at runtime. Before deploying, validate that the model reliably produces parseable JSON matching the schema across at least 20 varied inputs, and add a post-processing step that checks temporal ordering (each event's timestamp must be >= the timestamp of any event it references via caused_by).

The Incident Timeline Structuring prompt is designed to be called as a single step within a larger post-incident review pipeline. It expects a pre-assembled [INPUT] block containing raw chat logs, monitoring alerts, and deployment events. Do not stream raw, unbounded chat history directly into this prompt. Instead, pre-process the input to extract a relevant time window (typically from first alert to resolution) and deduplicate repeated messages. The prompt's few-shot examples teach the model to normalize timestamps to UTC ISO 8601, infer causal links between events, and annotate impact, so the application layer should not attempt this normalization beforehand—doing so would prevent the model from learning the pattern from the provided demonstrations.

Wire this prompt into your incident management system as a post-resolution processing step. After an incident is declared resolved, trigger a pipeline that: (1) queries your chat platform (Slack, Teams) and monitoring tools (PagerDuty, Datadog) for events in the incident window, (2) assembles the raw text into the [INPUT] placeholder, (3) calls the model with the prompt template, and (4) validates the returned JSON against the expected schema. The output schema should enforce an array of event objects with required fields: timestamp (ISO 8601 string), event_type (enum: alert, action, communication, resolution, impact), source (string), description (string), and causal_links (array of indices referencing prior events). Reject any response where events are not in ascending temporal order or where causal_links reference indices that don't exist. For high-severity incidents (SEV1/SEV2), route the structured timeline to a human incident commander for review before publishing to the postmortem document. Log the raw model response, validation errors, and any human corrections for future example drift detection.

Model choice matters for this workflow. Use a model with strong JSON mode and long-context handling, such as Claude 3.5 Sonnet or GPT-4o, because incident timelines often span thousands of tokens of raw chat and alert data. Enable structured output mode if available to reduce schema violations. Set temperature to 0 or near-zero to minimize timestamp hallucination. Implement a retry strategy: if validation fails due to schema non-conformance, retry once with the validation error message appended to the prompt as a correction hint. If the retry also fails, escalate to a human operator with the raw input and partial output. Do not silently accept timelines with missing events—compare the count of extracted events against a heuristic floor (e.g., at least one event per 30 minutes of incident duration) and flag anomalies. Finally, store the validated timeline in your incident database with a reference to the prompt version used, enabling regression testing when the prompt template is updated.