Source: [AI-drafted postmortems: check the timeline before naming a cause — Skills for Business]() [← All articles](https://skillsforbusiness.ai/blog/) Development · Guide # AI-drafted postmortems: check the timeline before naming a cause Keep event time, evidence, hypotheses and follow-up actions distinct when AI helps draft a software incident postmortem. [Skills for Business](https://skillsforbusiness.ai/blog/editorial/)2 November 20267 min read On this page 1. [Give the postmortem an evidence task](https://skillsforbusiness.ai/blog/ai-postmortems-timeline-cause-evidence/#give-the-postmortem-an-evidence-task) 2. [Research on diagnosis does not certify a new causal account](https://skillsforbusiness.ai/blog/ai-postmortems-timeline-cause-evidence/#research-on-diagnosis-does-not-certify-a-new-causal-account) 3. [Read a fictional five-event record carefully](https://skillsforbusiness.ai/blog/ai-postmortems-timeline-cause-evidence/#read-a-fictional-five-event-record-carefully) 4. [Preserve time, uncertainty and action state](https://skillsforbusiness.ai/blog/ai-postmortems-timeline-cause-evidence/#preserve-time-uncertainty-and-action-state) 5. [Investigate a cause instead of promoting a suspicion](https://skillsforbusiness.ai/blog/ai-postmortems-timeline-cause-evidence/#investigate-a-cause-instead-of-promoting-a-suspicion) 6. [Make follow-ups answer the unresolved findings](https://skillsforbusiness.ai/blog/ai-postmortems-timeline-cause-evidence/#make-follow-ups-answer-the-unresolved-findings) 7. [Review the account before sharing it](https://skillsforbusiness.ai/blog/ai-postmortems-timeline-cause-evidence/#review-the-account-before-sharing-it) 8. [Sources](https://skillsforbusiness.ai/blog/ai-postmortems-timeline-cause-evidence/#sources) What to take away - Attach timeline statements to evidence and distinguish event time from when someone reported it. - Treat suspected causes and suggested fixes as claims to investigate, not facts created by fluent prose. - Check impact and recovery separately from alert status, and give follow-ups explicit completion evidence. When AI helps draft a software incident postmortem, build a source-linked event table before accepting the causal story. Separate what the records show, what participants suspected, which actions actually completed and what remains unknown. A coherent account of an outage can still turn a plausible diagnosis into an unsupported fact. For a business operating customer software or internal tools, this affects which fixes receive time and money. If the report names the wrong cause, an apparently decisive action list may leave the relevant failure mechanism unexamined. This guide proposes a review method, illustrated with invented incident records. We have not investigated a real incident, tested a postmortem product or run an independent model evaluation. ## Give the postmortem an evidence task Google’s [SRE postmortem chapter](https://sre.google/sre-book/postmortem-culture/) describes a record covering impact, response, contributing causes and preventive follow-ups. It emphasizes learning without blaming individuals or teams. That is practitioner guidance about incident learning, not evidence that an automatically generated document has correctly explained a failure. Our recommendation is to ask the assistant for an evidence table and unresolved questions first. The initial deliverable should make it easy for an engineer to recover the source of each important statement. Drafting the final explanation comes after those statements have been checked. Set the source boundary explicitly. Identify the incident, collection window, services and available records: monitoring, deployment history, incident-channel messages, investigation notes and relevant change records. Record missing material. Access to the channel does not establish that the assistant saw every private thread, call or dashboard needed to understand the event. Use only approved tools and data-handling arrangements. Avoid copying customer payloads, credentials or unrelated staff conversations into the drafting context. References can point authorized reviewers to restricted evidence without reproducing sensitive contents in a broadly shared report. ## Research on diagnosis does not certify a new causal account [Zhang and colleagues’ January 2024 paper](https://arxiv.org/abs/2401.13810) studies root-cause recommendations using incident descriptions and similar historical examples. The Microsoft-authored work compares historical GPT configurations and includes evaluation by incident owners. Its evaluation distinguishes correctness from readability: an understandable suggestion and a correct one are different qualities. The paper’s discussion notes difficulties with novel incidents and outdated historical references. Its private incident corpus and historical model settings also limit what another team can infer from the results. This is research on a defined recommendation task, not proof that a current assistant can reconstruct causality from an arbitrary bundle of logs and chat messages. We do not transfer its reported performance figures to this workflow. A retrieved past incident may suggest a useful investigation. Keep it labeled as an analogy until evidence connects its mechanism to the current event. Matching phrases such as “timeout” or “connection pool” does not establish that two failures had the same cause. ## Read a fictional five-event record carefully Imagine the assistant receives the following **invented records** about a report-generation service. All displayed times are on the same fictional day and in UTC. The monitoring rule evaluates a rolling five-minute latency window. | Evidence ID | Recorded time and source | What it supports | What it does not establish | | --- | --- | --- | --- | | E1 | 09:00, deployment record | A release completed | That the release caused customer impact | | E2 | 09:07, monitoring record | A latency alert fired | The exact start of the underlying degradation | | E3 | 09:10, incident-channel message | Someone suggested pool exhaustion and said they would restart | That the diagnosis was correct or the restart completed | | E4 | 09:13, operations record | The restart completed | That it corrected the failure mechanism | | E5 | 09:18, monitoring record | The latency alert cleared | That all customer work or delayed reports had recovered | A tempting draft might say: “The release exhausted the connection pool at 09:00. The engineer fixed the incident by restarting the service, restoring all customers at 09:18.” That sentence adds a cause, an onset time, a proven remedy and a recovery scope absent from the supplied records. A supported account is narrower: “A release completed at 09:00 (E1). A latency alert fired at 09:07 (E2). At 09:10, a participant suspected pool exhaustion and proposed a restart (E3). Operations records show the restart completed at 09:13 (E4); the alert cleared at 09:18 (E5). The cause and extent of recovery require further verification.” The alert was active for eleven minutes in this fictional record. That calculation describes alert state, not necessarily customer-impact duration. The five-minute evaluation window and any detection delay prevent treating the alert timestamp as the exact moment the problem began. ## Preserve time, uncertainty and action state For real material, retain the original timestamp, its timezone and the source reference alongside any normalized display time. Distinguish when something happened from when a participant reported it. A message posted at 09:10 saying “this started earlier” supplies a reporting time and an uncertain event time, not a precise new timestamp. If source clocks disagree, preserve the discrepancy until it is explained. Do not let the assistant create second-level precision by ordering every record into a smooth narrative. Use an interval or an explicit unknown where that is what the evidence supports. Track actions through their states. “We should roll back” is a proposal. “Rollback started” is an attempt. A successful operation record supports completion of that operation. Evidence that the service and affected customer work recovered is a further claim. Each transition can matter to the incident explanation. Ask the assistant to flag state changes it inferred rather than observed. A useful review instruction is: “Attach a source ID to each event. Preserve suggestions and uncertain diagnoses as attributed statements. List missing evidence for claimed start, mitigation and recovery times. Do not fill timeline gaps from typical incident patterns.” This is a proposed instruction, not a tested prompt. ## Investigate a cause instead of promoting a suspicion For the fictional incident, the deployment and restart are candidates for investigation. Request evidence that could distinguish explanations: relevant pool metrics, changed configuration, traces and the behavior of delayed report jobs. The engineer should decide which evidence is appropriate to the service; the assistant can help organize questions and findings. Keep a suspected cause separate from its supporting and conflicting evidence. If the hypothesis is that a release changed connection handling, identify the actual change and the observed behavior it could explain. Record competing explanations and findings that remain inconsistent with the hypothesis. Do not assume that recovery after a restart proves why degradation began. Blameless writing still needs precision about actions and system conditions. Avoid converting a terse chat message into claims about an engineer’s competence, attention or intentions. Describe what information and controls were available, what happened and which uncertainties remain. An unsupported psychological explanation is no stronger because it appears under “root cause.” ## Make follow-ups answer the unresolved findings In its [April 2026 practitioner article](https://incident.io/blog/what-does-using-ai-for-post-mortems-actually-mean), incident.io distinguishes preparing scattered material from owning the interpretation and decisions. This is vendor-affiliated advice, not independent proof of its product’s accuracy or drafting speed. Here, it supports assigning responsibility for conclusions rather than treating a generated report as completed learning. For our example, “increase the connection pool” is not yet an established corrective action. A defensible initial follow-up might be to investigate whether pool saturation occurred and report the evidence. Another might be to establish whether delayed reports recovered after the alert cleared. These are investigation tasks with specified outcomes, not promises that the suspected mechanism has been fixed. For each approved follow-up, record the finding it addresses, owner, intended result and evidence needed for closure. Keep a proposed action distinct from a ticket that was actually created and assigned. Our [meeting-action handoff guide](https://skillsforbusiness.ai/blog/ai-meeting-actions-task-tracker-review/) covers that separate execution boundary. ## Review the account before sharing it Have the responsible incident reviewers inspect the chronology, impact statement, causal claims and follow-ups against their evidence. Check in both directions: each important sentence needs support, and consequential contradictory evidence must not disappear from the narrative. The [broader guide to checking AI answers](https://skillsforbusiness.ai/blog/human-review-ai-answers-evidence-check/) explains that support-checking principle; incident review adds the need to distinguish chronology, diagnosis and recovery. Save the reviewed version, source references and unresolved questions. If a leadership or customer summary is derived from it, preserve the qualifications that affect meaning. Removing technical detail should not turn a suspected cause into a confirmed one. Start with one bounded incident record and an accountable review owner. Accept AI assistance when it makes the evidence easier to inspect and the gaps easier to pursue. A postmortem can be useful while acknowledging an unresolved cause; it becomes misleading when certainty is supplied by the prose alone. ## Sources & further reading Sources checked for this article. Research findings and vendor claims are distinguished in the text. 1. [Postmortem Culture: Learning from Failure](https://sre.google/sre-book/postmortem-culture/)John Lunney and Sue Lueder; Google SRE · Accessed 2 November 2026 2. [Automated Root Causing of Cloud Incidents using In-Context Learning with GPT-4](https://arxiv.org/abs/2401.13810)Zhang et al.; Microsoft / arXiv · Accessed 2 November 2026 3. [What does using AI for post-mortems actually mean?](https://incident.io/blog/what-does-using-ai-for-post-mortems-actually-mean)incident.io · Accessed 2 November 2026 Produced with AI-assisted research and writing. Examples and recommendations are our editorial synthesis unless attributed. This article does not claim independent product testing or human expert review. [Read our editorial policy.](https://skillsforbusiness.ai/blog/editorial/) ## Keep reading [AI-added logging: define the event before copying the payload](https://skillsforbusiness.ai/blog/ai-added-logging-event-fields-review/)[Audit AGENTS.md for the behavior each instruction changes](https://skillsforbusiness.ai/blog/agents-md-instructions-behavior-audit/)