Post-incident flows: Bringing consistency to your post incident processes

To get the most out of your incident response processes, consistency is crucial.

The more predictable you can be whenever issues crop up, whether a small bug or a major outage, the quicker and more confidently you can respond.

In practice, incident response is equal parts knowing how to actually resolve the issue and having the confidence that the processes in place will help get you through without added stress.

But while it’s common for organizations to invest effort in ensuring their incident response is consistent, they rarely invest similar levels of effort in their post-incident processes. Things like ensuring the timeline and summary are accurate, tagging the incident with relevant data, and having a post-mortem document written and shared are left to chance.

This is exactly why we created Post-incident Flows.

They’re a solution that allows you to define your post-incident process to ensure that, no matter who’s running things or how long they’ve been around, your processes can be followed to a tee.

Learning from incidents: An ad hoc approach

Once the dust has settled on an incident, it’s common for responders to set aside some time to learn from what went wrong–this is a key part of building resilience and fostering a culture of continuous learning.

What this looks like in practice can vary quite a bit from organization to organization. However, the acknowledgment is there that something needs to happen after the incident to facilitate learning.

Sometimes, this can look like writing up a post-mortem document. For others, scheduling a debrief or post-mortem meeting with relevant stakeholders is the right plan. And for the rest, creating follow-up actions off the back of an incident is the status quo. And for many it’s all of these!

But again, this is conventional wisdom, and usually, the post-incident process can be a bit of an ill-defined black box. This makes it difficult for responders to know exactly what they should be doing at your organization.

Enter Post-incident Flows.

Learning with consistency: what are incident.io Post-incident Flows?

Post-incident Flows is a fully configurable process that helps you run post-incident actions using pre-baked tasks or custom-defined ones of your own. Using them helps you communicate what stage an incident is in after it’s been resolved, as well as who’s working on what.

Here’s how they work.

Before you close an incident, you’ll get a prompt that asks if you want to run your Post-incident Flow before closing it out for good. If you select “Yes,” we’ll move that incident to the first Post-incident Flow status, as defined by you or the default you selected, and list the tasks that need to be completed during that stage.

For example, one status can be “Documenting,” where you have a list of related tasks such as “Reviewing the incident timeline” and “Creating a post-mortem.”

These subsequent tasks can then be assigned to specific incident.io users.

Where applicable, steps completed within incident.io, such as creating an auto-generated post-mortem, will be automatically marked as completed. Tasks that need to be completed outside our platform, such as anything infrastructure, database, or follow-up-related, can be checked manually.

Once all the tasks have been addressed, we’ll automatically move the incident to the next phase, which could be another Learning Status, such as “Reviewing” or close it out completely.

The best part of Post-incident Flows? They’re fully configurable with incident.io.

You choose which tasks are required by each of your statuses and write instructions for each. If you’d rather plug-and-play, you can stick with the out-of-the-box defaults (we use these ourselves!)

Granted, for incidents of higher severity, your post-mortem steps might look a bit different. That’s why we allow certain types of incidents to have specific Post-incident Flow steps associated with them.

For example, you can create a Post-incident Flow that requires a post-mortem document and debrief task for every Critical incident.

You can always choose to opt out of Post-incident Flows at any point. If you do so, we’ll ask for a reason, which we will attach to the incident and post to the Slack channel to ensure that your team is kept up-to-date.

How will you use Post-incident Flows?

While we always ship with sensible defaults created by our own incident responders, we also believe in the power of customization.

Post-incident Flows are no exception.

So, while you can use the out-of-the-box checklist we provide, feel free to customize your Post-incident Flows to your unique needs! You can keep your processes high level, get deep into the weeds, or settle somewhere in the middle.

But no matter where you land, the most important thing to remember is that learning is a full-team effort that spans the incident lifecycle. Before, during, and after the incident are all opportunities to facilitate learning and build better resilience.

But once your incidents are wrapped up, Post-incident Flows can help you build that resilience with consistency.