We shipped incident timeline drafting in Parachute about fourteen months ago. The pitch was simple: after an incident is contained, the thing that takes the most engineering time is reconstructing what happened in sequential order. If we can generate that draft automatically from the events Parachute observed, the post-mortem starts from a better position.
The pitch was correct. But the path from "technically works" to "genuinely useful in practice" took longer than we expected, and the failure modes were specific enough that they are worth writing up.
What the timeline actually does
Parachute's incident timeline drafts from three sources: the structured event log of actions Parachute executed during the incident (isolation timestamp, log pull timestamp, each runbook step with its output), the raw evidence collected (CloudTrail events, process lists, network capture summaries), and the alert metadata from the originating system (PagerDuty or Datadog).
From those inputs, the model constructs a narrative in chronological order: when the alert was received, what Parachute did first, what the evidence showed at each stage, when containment actions were taken, and what the state of the system was at the time the incident was marked resolved.
The output format is a structured Markdown document with a summary paragraph at the top, a timestamped event table in the middle, and a "what we found" section at the bottom. Engineers get this delivered to their incident Slack channel before they have opened their post-mortem template.
Where it works well
Timeline drafting is most useful in two scenarios.
The first is when an incident had clear, discrete phases. An alert fires, a specific host is identified as compromised, containment runs, exfiltration is blocked. These incidents have a clean causal chain, and the model is good at expressing it. The human reviewer spends their time checking accuracy and adding context, not building the structure from scratch.
The second is when the incident happened overnight and the person writing the post-mortem was not the on-call who handled it. In that case, the timeline is not just a draft; it is the primary record of what the on-call observed. Without it, the post-mortem author is relying entirely on what the on-call remembers or wrote in Slack, which is often incomplete. Parachute's event log fills that gap with machine-precision timestamps.
Where it fails, specifically
Incidents that span multiple systems and involve human-to-human coordination are where the quality degrades noticeably. If an incident required a Slack thread where two engineers debated whether to isolate before or after pulling database logs, that decision and its reasoning will not appear in the generated timeline. The timeline shows what Parachute executed; it cannot reconstruct the deliberation that preceded it.
This matters for post-mortems because the interesting part of most incidents is not the sequence of events. It is the decision points: why did the on-call wait eight minutes before escalating? Why was the isolation delayed while the database connection was closed? A timeline that lists what happened but omits why decisions were made is accurate but incomplete as a learning artifact.
We handle this now by keeping the timeline as a structural scaffold and asking on-call engineers to annotate the decision points in a brief separate section. The model does not try to infer intent; that is the engineer's job. The division of labour is clearer once you have accepted that the generated timeline is a first draft with a specific scope, not a complete incident record.
The hallucination problem is smaller than you might expect, but it is real
We were most concerned about the model fabricating events: inventing a containment step that did not happen, or attributing a log event to the wrong timestamp. In practice, this is rare when the timeline is generated strictly from Parachute's own structured event log. The model is summarising structured data, not generating from memory.
Where it does occur is in the "what we found" interpretive section. When the evidence is ambiguous, the model sometimes presents a plausible interpretation as more certain than it should be. A CloudTrail event showing an API call to GetSecretValue at an unusual time is suspicious but not confirmed compromise. A badly-calibrated model writes "attacker accessed credentials" rather than "anomalous access to secrets manager, requires review."
We added an explicit prompt constraint that requires the model to qualify any interpretive statement with uncertainty language when the underlying evidence is not conclusive. It helps, but it requires ongoing attention. Engineers should treat the "what we found" section as a hypothesis list, not a findings report.
The thing that surprised us most
The highest-value use turned out not to be post-mortems at all. It was the live incident summary delivered to Slack while the incident was still open.
When a P0 fires at 2am and the on-call is handling containment, the leadership team or the incident commander joining from a different timezone does not want to read fifty lines of Slack thread to understand where things stand. A three-paragraph structured summary of "here is what Parachute has done so far, here is what the evidence shows, here is the current containment status" compresses the catch-up time significantly.
That summary is generated from the same event log as the post-mortem draft. We just generate it in present tense, on-demand, whenever someone calls the Parachute Slack command during an active incident. This was a small feature addition but it turned out to be the one that generated the most positive feedback from teams using Parachute in practice.
What it takes to make the output genuinely trustworthy
Three things make the difference between a timeline that engineers trust and one they ignore.
First: every claim in the timeline must trace back to a specific event in Parachute's log. If the timeline says "host was isolated at 03:14:23," that timestamp should be verifiable against the Parachute event record. We include source references inline so reviewers can verify without digging.
Second: the timeline must acknowledge what Parachute did not see. If the incident involved a server that was out of scope for Parachute's evidence collection, the timeline should say so explicitly, rather than silently omitting it. A gap in the timeline is different from an absence in reality.
Third: the interpretive section needs to be clearly labeled as such. The timeline's factual section and its interpretive section are different epistemic categories. Treating them as equivalent erodes trust when an interpretation turns out to be wrong.
We are not claiming the generated timeline replaces the post-mortem process. It replaces the blank-page problem and the manual reconstruction work. What happens after that, the root cause analysis, the remediation tracking, the process improvements, still requires human judgment. That is where the post-mortem process earns its cost.
