Incident Post-mortems: Every Revision a New Version, Every Action Item Filed Once

A post-mortem is rewritten more often than it is read

The first version is the easy one. The timeline comes from the deployment events, the contributing changes from the pull requests that shipped in the window, and the action items from the review meeting. Then the review lead wants the contributing-factor lines in a different shape, support wants the impact written for the people it goes to, and platform changes which deploys count as part of the change set. Each note means a new version, and every earlier one has to stay exactly as it was approved.

The evidence is in Vercel: the project's deployments and the production alias's event stream, both read only. The pull requests are in GitHub, which is also where action items are filed as issues. The post-mortem standard and every review note sit in Google Drive, each version is a Google Doc, and the conversation runs in Slack. Editing the last version in place, filing the action items twice or carrying an old change set into a new rule are the mistakes that make a post-mortem hard to trust.

Who works in the room

Each incident gets its own Kylon room. Ada is the default agent and writes every version, so a new note goes to Ada whether or not anyone names it. Myco checks each version against the last and owns the tracker issues, as the room guidelines say, so filing happens once and in one place. Ada hands over by opening a thread for Myco whose first message is the brief: which version, which note, and which sections should and should not have changed.

Five versions of one incident

Every version is a new document. Nothing is published, filed or shared until the incident review lead approves it.

When the note changes the shape, and when it changes the facts

Most notes change how something is written, not what happened. For those, Ada restates the whole post-mortem in a new Google Doc and changes only the sections the note covers, and Myco compares the new version with the last one line by line. If the timeline moved when the note was about action items, the version goes back to Ada before anyone outside the room sees it. Earlier docs are never edited; each stays as it was approved.

Platform's note on v4 is different, because it changes a rule rather than a format. Under the new rule only deploys promoted to the production alias belong in the change set, so Ada re-derives the set from the Vercel records, which have not changed since v1. Two changes leave and their lines go with them; one joins and is written in the same shape as the rest. The timeline, the action items and the six tracker issues filed with v3 stay exactly as they are, and the run history shows which records each version was built from.

What the checks catch

• A new version that edits an earlier doc instead of being written as its own
• Tracker issues proposed again after v3, which Myco drops before the lead sees them
• An action item in the doc that was never agreed at the review meeting
• A change kept in the set under the new rule only because it was in the set before
• A timeline or impact line that moved in a version whose note did not ask for it

What stays with people

• Approving each version before it is published or shared
• Approving the tracker issues before they are filed, once
• Reading a note whose wording leaves room for doubt, and deciding what it means
• Deciding who outside engineering receives the post-mortem

Integrations in this workflow

Kylon is not an incident management tool and it does not replace one. It pulls from the hosting platform and the code host, writes into the documents the team already works in, and holds the coordination between them.

• GitHub
• Google Docs
• Google Drive
• Slack
• Vercel

• Vercel supplies the project's deployments and the production alias's event stream, read only
• GitHub supplies the pull requests and holds the tracker issues for the action items
• Google Docs holds each version of the post-mortem as its own document
• Google Drive keeps the post-mortem standard, the review notes and the roster of action item owners
• Slack is where the review happens and where each approved version is shared

Where to start

Try it on your next incident review. Connect the Vercel project read only and the repository where action items are filed, give the room the Drive folder that holds your post-mortem standard, and write one rule in the room guidelines: every version is a new document, earlier ones are never edited, and tracker issues are filed once, after the review lead approves them.

“Five versions, five documents and one set of tracker issues. Anyone can open v2 and read exactly what was approved that day.”

Set it up with your agent

Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.