Incident Lifecycle

Customise your Incident Lifecycle to your specific incident management process

incident.io Engineering Team avatar
Written by incident.io Engineering Team
Updated over a week ago

Your incidents go through a lifecycle, for example:

Declared ➡️ Investigating ➡️ Fixing ➡️ Monitoring ➡️ Closed

You can customise the lifecycle of your incidents, to match your organisation's process at Settings > Respond > Lifecycle

There are three main stages of the incident lifecycle you can configure: triage, active, and post-incident.

You can also configure how timestamps are set when an incident moves between statuses.


1. Triage

You can learn more about triage incidents here. Incidents created automatically from an alert or via our API will start in triage. You can configure whether or not incidents created manually can go through triage here.


2. Active

These statuses indicate the condition of your incident at a single point in time, while there's still ongoing impact and responders are working towards a resolution. The default statuses are: Investigating, Fixing, and Monitoring.

3. Post-incident

Once the immediate impact is over, an incident can then enter a post-incident flow, where you can define tasks for responders to complete now that there's time to reflect on what went wrong, and how to prevent it happening again.

Define your process in Settings > Improve > Post-incident flow, and set the rules for which incidents should automatically enter the flow. Responders can always opt-in or opt-out of the flow.


4. Timestamps and metrics

Timestamps are a way to store structured data about your incidents. These are useful for reporting and analysis.

By default, there's a corresponding timestamp for each status. For example, "Fixed At" is set to the first time the incident changed to the "Monitoring" status.

Timestamps can be set in two ways:

  1. Manually - set by a responder, from the Incident Homepage

  2. Automatically - based on an incident status transition

Often, the impact will begin sometime before an incident is declared, so a good example of an additional timestamp could be "Impact Started At", which would be manually set by a human. So, if you wish to calculate the time to resolution for your incidents, it would be more accurate to measure from when the impact started, as opposed to when the incident was declared.

You can define custom metrics here too, as the difference between two timestamps:

These are available in the MTTX tab in Insights.

Did this answer your question?