Engineering
The incident ended and the writeup never started
The timeline assembled from the channel and the deploy history, with the gaps left honest.
What the worker does
An AI worker turns an incident into a timeline draft while the details are still recoverable. It reads the incident channel and deploy history through the Slack and GitHub connections, orders the events by timestamp, and marks every gap as unknown rather than filling it in. Action items become tasks in the workstream. Naming the contributing factors is written by the people who were there.
- Trigger
- When the incident closes
- Connections
- Slack, GitHub, Notion
- Written by a person
- Contributing factors
The writeup competes with recovery
The incident ends at 2am. The people who understand it best spend the next day catching up on everything the incident displaced, and the writeup slides to Friday, then to next week. By the time somebody opens the channel, the details have blurred and the reconstruction takes three times as long as it would have on the morning after.
Assembling a timeline is not the hard part of a postmortem. It is the part that costs the most time and produces the least insight, and it is the part that decays fastest.
How the timeline gets built
- 1
Read the incident channel
Every message in the channel across the incident window, with timestamps and authors preserved. The channel is usually the only complete record of what people believed at each moment.
- 2
Overlay the deploys
Merge and release timestamps from the repository, placed on the same timeline. The relationship between a deploy and the first alert is often the whole story and is tedious to reconstruct by hand.
- 3
Mark the gaps
Twenty minutes with no messages is reported as twenty minutes with no messages. The worker is briefed to write unknown rather than to produce a plausible sentence, because a plausible sentence in a postmortem is worse than a hole.
- 4
Separate observation from explanation
The draft holds what happened. The section on why it happened arrives empty, with the questions the timeline raises listed underneath it.
- 5
Turn follow-ups into tasks
Every action item mentioned in the channel becomes a task in the workstream, with owner and date left blank for the review meeting to fill in.
What is reconstructed, and what is not
| Reconstructed from records | Only from the people involved |
|---|---|
| When the first alert fired | Why nobody acted on it for eleven minutes |
| What was deployed, and when | Why the change was believed to be safe |
| Who joined the channel and when | Who thought they were leading |
| What was tried, in order | What was ruled out silently and why |
Why it runs immediately
Assign the task when the incident closes and a cloud machine picks it up straight away, including at 2am when everyone involved has gone to bed. The draft is waiting in the morning, built from a channel nobody has had time to scroll away from yet.
The document lives in Polaris Docs with versioning and review comments, so the review meeting edits one artefact instead of circulating four copies.
Questions people ask
+Can it write the whole postmortem?
It writes the timeline, the deploy overlay, the open questions and the follow-up tasks. The analysis of contributing factors is left empty on purpose, because that section is the reason the document exists and it depends on what people believed rather than what systems recorded.
+What if the incident was handled in a call, not in Slack?
Then the timeline will be thin and the draft will say so, with the gaps marked explicitly. Teams that read one sparse draft tend to start narrating in the channel during the next incident, which is a useful side effect.
+Does this need access to our monitoring tools?
The Polaris connection catalog covers Slack, GitHub, Notion, Google Drive, Supabase and the other listed tools, not observability platforms. In practice the alert messages posted into the incident channel carry most of the monitoring timeline anyway.
+Who owns the follow-up tasks it creates?
Nobody until a person assigns them. The worker creates them in the workstream with owner and date blank, because assigning follow-up work to someone who was up all night is a decision for the review meeting.
Related
The engineering work that is not writing code
Five jobs that sit between an engineer and the code, and what an AI teammate does with each.
Forty new issues on Monday, half of them the same bug
Every new issue checked for duplicates, version and repro before an engineer opens it.
The README describes a version of the code that no longer exists
A monthly list of statements in your docs that the code no longer supports.
Connect Slack to Polaris
Six scopes, no access to direct messages, and a bot that only reads the channels somebody invited it into.
Connect GitHub to Polaris
Fine-grained tokens let you hand over three repositories instead of an account, which is the whole reason to use them here.
How long an agent session can run, and what happens when it ends
Every agent runtime has bounds. The useful thing a vendor can do is tell you what they are.
Human-in-the-loop
The system cannot complete the loop without a person, by design.