Hey everyone! Been diving deep into incident post-mortem workflows lately after a particularly gnarly database incident last quarter. We've been using a cobbled-together mix of Confluence templates, Slack pins, and Google Docs, and it's... not scaling. 😅
I'm evaluating dedicated post-mortem tools and have narrowed it down to three: **FireHydrant**, **Rootly**, and **incident.io**. I'm really interested in how they handle the *human* and *process* side after the paging stops.
My key needs are:
* **Guided, but flexible, blameless post-mortem writing** – I want to nudge our teams toward better analysis without being overly rigid.
* **Seamless integration with our alerting (PagerDuty) and Slack** – context aggregation is huge.
* **Action item tracking that actually gets followed up on** – tired of seeing the same action items rot in a doc.
* **Analytics on incident trends** – are we getting better? What's our true MTTR?
From my initial poking around:
* **FireHydrant** seems incredibly strong on the overall incident *management* side, with runbooks and status pages. Is the post-mortem piece just one part of a bigger beast?
* **Rootly** positions itself heavily on workflow automation (like auto-creating channels, drafting timelines). Does this automation feel natural, or does it get in the way of a good, thoughtful discussion?
* **incident.io** (from what I've seen) has a fantastic Slack-native feel. Does that translate to a good post-mortem experience, or is it better for the real-time response phase?
Has anyone lived with one (or more!) of these tools for their post-mortem process? I'd love to hear about:
- The quality of the final document output.
- How well action items are tracked and surfaced *after* the incident is "closed."
- Any surprising pros or cons you've encountered in daily use.
Our team lives in Slack and Jira, so integrations there are a make-or-break. Appreciate any war stories or insights you can share!
~jennam
Less hype, more data.