Writing Incident Postmortems With LLMs in November 2026: Build the Timeline From Real Timestamps, Keep It Blameless, and Give Every Action Item an Owner

An outage ends, everyone is tired, and somebody still has to write the postmortem. That document is where a team turns a bad night into lasting fixes, so it is a tempting place to hand work to an LLM. A model is genuinely good at the slow parts: turning a pile of chat messages and alert timestamps into a readable timeline, drafting neutral prose, and grouping follow-up work. It is also good at something you do not want: writing a confident, tidy story about causes nobody verified.

This guide shows a practical way to use an LLM for incident postmortems without letting it invent the incident. The short version: feed it real evidence, make it build the timeline only from timestamps it can point to, keep the language blameless, and refuse to publish any action item that lacks an owner and a way to check it was done.

Accident investigators start from recorded data, not memory. A good postmortem timeline should too. Image: Flight data recorder by NTSB, public domain, via Wikimedia Commons.

What a good postmortem needs to contain

Before involving a model, agree on the shape of the document. Most teams settle on some version of these sections:

• Summary: two or three sentences on what broke, who was affected, and for how long.
• Impact: concrete effects such as failed requests, delayed jobs, or customers who could not log in, with numbers taken from your own dashboards.
• Timeline: timestamped events from first signal to full recovery, in one stated time zone.
• Contributing factors: the conditions that allowed the incident, usually more than one.
• What went well and what did not: detection, escalation, communication, and tooling.
• Action items: specific changes, each with an owner, a priority, and a tracking ticket.

Put this template in the prompt every time. A model that gets a fixed structure produces far more consistent drafts than one asked to "write a postmortem."

Step 1: Gather the raw evidence first

The model can only be as accurate as what you give it. Collect the primary sources while they are fresh:

• The incident chat channel export, with timestamps and authors.
• Alert history from your monitoring system: when each alert fired and resolved.
• Deploy and config change history around the incident window.
• Key log lines or error messages, already filtered to the relevant window.
• Status page updates and any customer support notes.

Before pasting any of this into a hosted model, strip secrets, tokens, internal hostnames you consider sensitive, and personal data about customers. Incident channels are full of pasted credentials and customer emails because people were moving fast. Check your organization's policy on which models may see production data.

Normalize timestamps before the model sees them

Chat exports, alerting tools, and logs often use different time zones and formats. If you leave that to the model, it will happily merge 14:05 UTC and 14:05 Pacific into the same moment. Convert everything to one zone with a small script first. For example, a few lines of Python with datetime.fromisoformat() and astimezone(timezone.utc) are enough to rewrite every line as 2026-10-30T21:14:03Z [source] message. Then sort the combined file. Now the model is reading one ordered stream instead of guessing.

Step 2: Build the timeline from evidence only

The timeline is where models add the most value and where hallucination does the most damage. Ask for it in a format that forces traceability:

You are helping write an incident postmortem.
Below is a merged, time-sorted evidence file. All times are UTC.

Build a timeline table with columns: time, event, source line.
Rules:
- Every row must quote or reference a specific line from the evidence.
- Do not add events that are not in the evidence.
- If two sources disagree about a time, list both and mark "conflict".
- Mark the first alert, the first human response, mitigation, and full recovery.
- If something important seems missing (for example, no record of when
  the rollback started), say so in a "gaps" list instead of guessing.

EVIDENCE:
...

The "source line" column is the important part. It lets a reviewer spot-check any row in seconds. The "gaps" list is the second most important part, because a missing rollback time is something a human on the call can fill in, while an invented one quietly becomes official history.

From that timeline you can compute the numbers people ask about: time to detect (incident start to first alert), time to respond (first alert to first human action), and time to recover. Calculate these yourself from the table rather than asking the model to do date arithmetic in its head.

Step 3: Draft contributing factors, then challenge them

Next, ask for a draft of contributing factors, but require evidence and labels:

Using only the timeline and evidence above, list possible contributing
factors. For each one give:
- the factor in one sentence
- the evidence that supports it (quote the line)
- confidence: confirmed / likely / speculative
- what we would need to check to confirm it

Prefer system and process conditions over individual actions.

Then read the list critically with the people who were on the incident. Models lean toward the single neat explanation, such as "the deploy at 21:02 caused the outage," when real incidents usually involve several factors: a risky change, a missing alert, a runbook that pointed at the wrong dashboard, and a retry storm that turned a small failure into a large one. Ask directly: "What else had to be true for this to cause an outage?" That question tends to surface the deeper factors.

Anything still marked speculative after review either gets investigated or goes into the document clearly labeled as unconfirmed. Do not let the model promote a guess to a root cause because it reads well.

Investigators look for the conditions that allowed a failure, which is the same mindset a blameless postmortem needs. Image: NTSB investigators in the Fern Hollow Bridge wreckage by National Transportation Safety Board, public domain, via Wikimedia Commons.

Step 4: Keep the language blameless

A blameless postmortem focuses on why the system made a mistake easy, not on who made it. Raw incident chat is rarely written that way, and models will often copy its tone. Give the model explicit rewriting rules:

• Describe actions by role, not by name: "the on-call engineer restarted the service," not "Sam restarted the service."
• Avoid words like "careless," "should have known," or "failed to."
• Explain why a decision made sense with the information available at the time.
• Keep facts intact; blameless does not mean vague.

A useful before-and-after example: "Alex pushed a bad config without testing it" becomes "A config change reached production without passing through staging, because the deploy tool allowed direct production pushes for config files." The second version is more useful because it points at something you can fix.

After the rewrite, search the draft for every person's name and for phrases like "should have." It takes a minute and catches what the model missed.

Step 5: Turn findings into owned action items

Postmortems fail most often at the end. The document gets written, the action items are vague, and nothing changes. LLMs make this worse if you let them, because they generate long lists of reasonable-sounding items like "improve monitoring" or "add more tests."

Ask for action items in a strict format and reject anything that does not fit:

For each contributing factor, propose at most two action items.
Each item must have:
- a specific change ("Add an alert when queue depth exceeds 10,000
  for 5 minutes"), not a goal ("improve monitoring")
- type: prevent / detect / mitigate
- a way to verify it is done
- owner: leave as TBD
- priority: leave as TBD

Leaving owner and priority as TBD is deliberate. Those are decisions for the team in the review meeting, not for a model. Once a human fills them in, create the tickets and link them from the document. An action item without a ticket and an owner is a wish.

Also cap the list. Five well-chosen items that actually ship beat twenty that sit in a backlog. Ask the model to rank its suggestions by how much risk each removes, then let the team cut.

Step 6: Review before you publish

Treat the AI draft like a draft from a new teammate who was not on the call. Before publishing, check:

1. Timeline accuracy: spot-check at least the first alert, mitigation, and recovery rows against their source lines.
2. Impact numbers: every number should come from a dashboard or query you can link, not from the model.
3. Contributing factors: each is either confirmed or labeled as unconfirmed.
4. Blameless language: no names attached to mistakes, no "should have."
5. Action items: each has an owner, a priority, and a ticket link.
6. Sensitive data: nothing secret or customer-identifying slipped back in.

Then have at least one person who handled the incident read the whole thing. They will notice the event that happened in a hallway or on a voice call and never made it into the chat log, which no model could have known about.

A workable division of labor

Used this way, the model does the tedious assembly and first-draft writing, and people keep the judgment calls:

• Model: merging and ordering evidence, drafting the timeline with citations, listing candidate factors with confidence labels, rewriting in blameless language, and proposing specific action items.
• Humans: collecting and redacting evidence, filling timeline gaps, confirming causes, choosing which action items matter, assigning owners, and approving the final document.

That split can cut the time from "incident resolved" to "postmortem reviewed" noticeably, which matters because the details fade fast. Just keep one rule in front of everyone: if a sentence in the postmortem cannot be traced to evidence or to a person who was there, it does not belong in the record.