Skip to main content
Once you’ve got a post-mortem process running, there are parts of it that really shouldn’t require a human to remember to do them. Sharing the finished document in Slack, exporting a copy to your knowledge base, notifying a specific team when a post-mortem for their service is completed. These are the kinds of things that should just happen. Workflows let you automate all of this. You set up a trigger, add some conditions, and define what should happen. The trigger for post-mortems is A document is created or updated, which fires when a post-mortem is created or when its status changes. From there, you can build whatever automation makes sense for your team.

Announcing completed post-mortems in Slack

This is probably the most common workflow people set up, and it takes about a minute to configure. The idea is simple: every time a post-mortem is marked as complete, a message is automatically posted to a Slack channel. Your team sees it, they can click through to read it, and nobody had to remember to hit the share button. To set this up:
  1. Create a new workflow with the A document is created or updated trigger.
  2. Add a condition that checks if the post-mortem status is Complete.
  3. Add a Post to Slack channel step, pick the channel you want to announce in, and write the message. You can use variables to include the incident name, severity, and a link to the post-mortem.
This is different from the manual sharing feature (see Sharing & exporting) because it happens automatically. You don’t have to rely on someone remembering to share the document, and you can guarantee that every completed post-mortem gets announced in the same place. You can also get creative with the conditions. Maybe you only want to announce post-mortems for critical incidents in a company-wide channel, but all post-mortems go to an engineering channel. You can set up multiple workflows with different conditions to handle this.

Automating exports

This one is really useful for larger organizations. You want to write your post-mortems in incident.io because that’s where the incident data lives, but you also need a copy in Confluence, Notion, Google Docs, or SharePoint because that’s where your org keeps its long-term documentation. You could remember to hit the export button every time, but that’s exactly the kind of thing that gets forgotten on a busy week. Instead, you can set up a workflow to do it for you:
  1. Create a new workflow with the A document is created or updated trigger.
  2. Add a condition that checks if the post-mortem status is Complete.
  3. Add an Export post-mortem step and select your export destination.
Now every completed post-mortem is automatically exported to your knowledge base. No manual step, no forgotten exports. One thing to watch out for: if someone changes the status back and forth (say, from Complete to In Review and back to Complete), the workflow will fire each time the document hits Complete. To prevent duplicate exports, add a condition that checks whether the document has already been exported. That way the workflow only runs the export the first time.

Other ideas

The trigger and condition system is flexible enough to support plenty of other use cases. A few ideas:
  • Notify a team lead when a post-mortem for their service is completed, so they can prioritize reading it.
  • Create a follow-up automatically when a post-mortem is completed, reminding someone to present the findings at the next team meeting.
  • Send a message to Microsoft Teams if that’s where your team communicates, rather than Slack.
The building blocks are all the same: trigger on document created or updated, filter with conditions, and pick your action.