Multiple incident lifecycles and post-incident flows

At incident.io we use incidents for lots of different things - not just product bugs but also security reports and customer support issues.

Having the same set of statuses for every type of incident doesn’t always work very well. In the heat of an incident having to adapt to a set of statuses that don’t really make sense is the last thing you need to be worried about.

From today, you can configure different sets of statuses for different incident types.

For example, you can keep using Investigating → Fixing → Monitoring for your engineering incidents while your Security team can use Identifying → Containing → Eradicating.

Different lifecycles can also enter different post-incident flows, and have different rules for which incidents should run that process and which can skip it ✨

Each flow can have its own set of post-incident tasks for responders to complete after the initial impact of an incident is over. For example, after a Security incident you may need to notify specific stakeholders, or make a record in an internal tool. That can now be configured just for security incidents.

👉 Nudge to set timestamps

You can now configure a nudge to remind responders to set a timestamp, such as "Impact started at". This is useful if you have one or two timestamps that you want to encourage responders to set manually during an incident.

🚀 What else we’ve shipped