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 -> Core -> Lifecycle
There are two main concepts: statuses and timestamps, which are described below
1. Statuses
Statuses indicate the condition of your incident at a single point in time. The default statuses are: Investigating, Fixing, Monitoring and Closed.
They are split into two categories: live statuses and closed statuses.
Live statuses are when the incident is actively being worked on
Closed statuses are when the incident response is over, and it's time to learn from the incident and implement follow-ups.
A good example of an additional status could be "Resolved". This would exist after "Closed", to be used when a post-incident review has been completed and all the follow-ups are exported and assigned to teams in your issue tracker.
2. Timestamps
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 three ways:
Manually - set by a responder, from the Incident Homepage
Automatically - When an incident is declared
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.