Software & TechnicalFree
Postmortem Report From Incident Data
The timeline rebuilt from your alerts and chat transcript, with the actions that made the incident worse separated from the ones that ended it.
River's postmortem tool reads the incident record you already have. The PagerDuty export, the monitoring alerts, the log excerpts and the channel transcript go in, and the written postmortem comes out. Every timeline row carries the source it was read from, so a disputed minute is settled by opening one link. Impact is counted against the alert data rather than estimated afterwards. Action items land in a sheet with one owner each, typed by whether they prevent the failure, detect it sooner, shorten it, or change the process.
What ranks for this search is a form. The best of them are well designed and still leave the hard part with you. PagerDuty's template names the times it wants, down to the moment the status page went public, then gives you a blank column headed links to tools and logs. That blank column is the job. Filling it means scrolling a channel three days later and reconciling three tools whose clocks disagree, which is why the postmortem slips past the week it was meant to land.
Built for the on-call engineer who owns the writeup, the engineering manager who has to present it, and the reliability team that needs the action items followed through. Reach for it when the incident is over and the record is scattered across four tools. If the record itself is still scattered across logs, alerts, and deploys, incident timeline reconstruction builds the ordered timeline this tool then turns into the writeup. What comes after is usually a runbook built from that alert's own resolution history, so the next on-call starts from what has actually worked.
An outage runs on more than one clock
Most templates ask how long it was down and give you one field. Google's published example postmortem marks five separate moments instead. The outage begins at 14:54 and the incident at 15:01, mitigation lands at 15:36, impact ends at 16:00, and the incident closes at 16:30 on a stated exit criterion. That is 66 minutes of outage sitting inside 89 minutes of incident. Report one number and you have quietly chosen which of the two questions you are answering.
The gap those clocks expose is the one nobody records. Atlassian's worked example carries 130 minutes between 14:20, when build engineering reports a problem, and 16:30, when the team recognizes the failures as an incident and runs it as one. That is two hours in which the incident did not exist on paper. The impact section of the same template asks for a single span in hours and minutes, so its own example has nowhere to put them.
Provenance on each row is not a new idea either. PagerDuty's incident response documentation requires that each timeline item identify a metric or the page its data came from. It asks for the queries too, so others can see how the data was gathered. Its own method for finding the responders is to go through the history in Slack. Reading that record is what a machine is good at, and it is the half of the work every template hands back to you.
How it works
Paste the record
Drop in the incident export, the alerts, the log excerpts and the channel transcript.
River orders the events
Every entry placed on one clock with the source it came from, and clock skew noted.
Read the postmortem
The written document, the action item sheet with owners, and a failure path diagram.
Fill the gaps
Answer the questions it flagged, add the log lines it asked for, and rerun.
What you get
- A timeline built event by event, each row carrying the alert or message it came from
- Six moments kept apart: impact began, paged, declared, mitigated, impact ended, closed
- The actions that made it worse listed separately from the ones that resolved it
- Impact quantified from the alert and log data rather than estimated after the fact
- Action items in a sheet, one owner each, typed prevent, mitigate, detect or process
- The gaps in the record named, rather than smoothed over with a plausible sequence
Common questions
What does it actually need from me?
Whatever you have. An incident export with timestamps is the strongest input, and the channel transcript is usually the most useful because it holds the decisions. Log excerpts, alert notifications and deploy records all get read. If you only have the chat, it works from that and tells you which timeline rows ended up unsourced as a result.
Does it stay blameless?
Yes, and the definition matters more than the word. Google's postmortem culture chapter puts it as a document that "assumes that everyone involved in an incident had good intentions and did the right thing with the information they had". So actions are described by role, alongside what that person knew at the time. For the longer argument, see the guide on writing blameless incident reports.
What happens where the record has gaps?
They get named. A twenty minute stretch with no alert, no message and no deploy entry appears as a gap in the timeline, not as a smoothed sequence. That is the part worth your attention, because a causal claim across an unrecorded window is a guess. You are told which window it is and what would settle it.
How does it decide the root cause?
It proposes one and shows the chain it followed, then marks where the chain rests on inference rather than a record. Contributing factors stay separate from the trigger, because the config push that surfaced a latent bug is not the same as the bug. Pinning that push to a commit is easier if you also have a changelog built from the git history.
Are the action items usable, or just a list?
They are typed and owned, which is the difference. Google's critique of a bad postmortem is that all of its action items carried equal priority, leaving no way to decide which to tackle first. Only one had a tracking bug. So each item here gets one owner, a type of prevent, mitigate, detect or process, and a defensible priority. Vague verbs like improve get rejected.
Is this a postmortem, an RCA, or a retrospective?
A postmortem, in the incident sense. A retrospective looks at how a team worked over a period and is about continual improvement. A root cause analysis is the investigation you run when something broke. This produces the incident document with that analysis inside it, and it is the wrong tool for reviewing a finished project.
Who should be in the review, and how much preparation do they need?
The commander, whoever was hands on keyboard, and one person who was not in the room. The run does the preparation, which is the part that usually gets skipped. Everyone arrives having read a timeline that already agrees with the record, so the meeting argues about causes and priorities rather than about what time something happened.
Postmortem Report From Incident Data
Fill in the form and your workspace opens with the work already underway.