How to write an incident timeline for a postmortem

What a timeline is for

A postmortem timeline is a chronological record of an incident: what happened, when it happened, and what people tried in response. It exists so a reader who was not in the room can reconstruct the incident without asking anyone. That reader might be a new teammate, a manager, an auditor, or you in six months.

The timeline is also the anchor for everything else in the postmortem. The "impact" section cites it. The "root cause" section references it. The "actions" section grows out of it. If the timeline is wrong or vague, every section built on top of it inherits the problem.

What to capture

During the incident, write down the things that are hard to reconstruct later:

• Every time something happened. Alerts, deploy starts, config changes, restarts, escalations, rollbacks. A rough time is better than no time — you can correct it later, but you cannot remember it later.
• What was tried, including dead ends. The command that failed and the dashboard that was down are as important as the fix that worked. They explain why the incident took as long as it did.
• Who was involved. One line per person is enough: "10:23 — Sarah paged, started checking the load balancer."
• What changed. Deploys, config edits, traffic spikes, third-party announcements. Changes are the usual suspects for both cause and resolution.

How to format it

The single most useful habit is to start each line with a timestamp. Formats that parse reliably are HH:MM (10:15), HH:MM:SS (10:15:32), and ISO 8601 (2026-08-15T10:15:00Z). After the timestamp, write one short line of what happened:

Lines without a timestamp — "checked the DB config", "thought it might be a deploy issue" — are still useful. Keep them; they attach naturally to the nearest preceding timestamp as context notes. The important thing is to capture the thought while it is fresh, not to format it perfectly in the moment.

Leave the gaps visible

Every real incident record has holes in it. There will be a stretch where nobody wrote anything down, a decision that happened in someone's head, a period where the on-call was on a call. The honest move is to mark that hole rather than paper over it.

Logtrace does this automatically: a window of five minutes or more with no entries is shown as an amber gap with its duration and time range. You can then decide what to do about it — ask the person involved, check dashboard history, or write "unknown" and add a follow-up. A postmortem that invents a confident narrative to hide a gap is worse than one with a visible hole, because the invented version cannot be trusted anywhere else.

Bringing it together

When the incident is over, paste your raw notes into Logtrace and you get back the structured timeline — time-ordered entries, notes attached to their timestamps, gaps flagged, critical and resolved events highlighted. Export it as Markdown and drop it into your postmortem document as the timeline section.

What Logtrace does not do is decide what the timeline means. It does not connect to your monitoring systems, page anyone, or write your analysis. It formats what you give it, honestly and without inventing anything — which is exactly the property a postmortem timeline needs.