Incident → postmortem first draft
The tedious first draft of a postmortem writes itself from the incident timeline.
Overview
After an incident is resolved, an agent assembles a timeline from alerts, Slack messages, and deploy logs, and produces a first-draft postmortem for the on-call engineer to refine.
How this workflow works
- Problem it solves
- Postmortems get skipped or delayed because reconstructing the timeline by hand is tedious.
- Expected outcome
- A structured first-draft postmortem with a timeline exists within an hour of an incident closing.
- Setup time
- 1 hour
Steps
- 01Incident resolvedThe incident is marked resolved in the incident tool.
- 02Assemble timelineAn agent pulls alert timestamps, Slack thread messages, and deploy events into one timeline.
- 03Draft postmortemA first draft with timeline, impact, and open questions is generated for the on-call engineer.
Prerequisites
- Incident management tool
- Slack export access
- Deploy log access
This workflow uses
More in DevOps & Infrastructure
Reviews (5)
Would recommend with caveats
Good value for the price, and the team behind it ships improvements fast. Just don't expect it to read your mind about internal conventions on day one.
- Frequent updates
- Fair pricing
- Some rough edges in edge cases
Exactly what we needed
Replaced a manual process that was eating an hour a day across the team. Straightforward to configure and it's held up under real usage.
- Saves real time weekly
Useful but needs guardrails
Works well for the narrow case we use it for. We had to add explicit boundaries after it did something a bit too enthusiastic in week one.
- Capable when scoped well
- Needs explicit boundaries
- Support response was slow
Solid, with a learning curve
Took about a week to tune the config to our repo's conventions, but once it clicked it's been reliable. Wouldn't hand it the riskiest changes unsupervised yet.
- Good defaults
- Responsive to feedback
- Setup docs assume more context than we had
Genuinely changed how our team ships
We put this in front of real work for three weeks before trusting it near main. It's now part of the default flow, and reviewers spend their time on the parts that actually need judgment.
- Fast to set up
- Caught real bugs
- Occasional context loss on very large diffs