Overview
Rootly manages incidents through the following stages. Each stage is represented as the incident status.Triage
The triage status is used for potential issues that have not been confirmed as an incident. Placing an incident in the triage status allows teams to limit the blast radius of any notifications and keep the initial investigation to a small group of responders. Incidents can be declared into the triage status by selecting the Mark as In Triage checkbox. The data value for the triage status is in_triage. When an incident is in the triage status, the{{ incident.in_triage_at }} timestamp will be automatically recorded.
This timestamp will NOT be logged if the incident was never triaged.
Started
Once an incident is in the started status, it signifies that the incident has been confirmed as a real incident. To declare an incident directly into the started status, simply leave the Mark as In Triage checkbox unchecked. The data value for the started status is started. When an incident is in the started status, the{{ incident.started_at }} timestamp will be automatically recorded.
Mitigated
An incident moves to the mitigated status once its impact has been contained. However, this does NOT mean the incident has been officially fixed. An incident can be progressed to the mitigated status by using the /rootly mitigate command or via the Mitigate button. The data value for the mitigated status is mitigated. When an incident is in the mitigated status, the{{ incident.mitigated_at }} timestamp will be automatically recorded.
This timestamp will automatically be set to the same value as the {{ incident.resolved_at }} timestamp if the mitigated status is skipped.
Resolved
An incident is considered resolved once the issue causing the incident has been fixed. An incident can be progressed to the resolved status by using the /rootly resolve command or via the Resolve button. The data value for the resolved status is resolved. When an incident is in the resolved status, the{{ incident.resolved_at }} timestamp will be automatically recorded.
Cancelled
CANCELED - The incident can be canceled if it’s determined that it’s not an actual incident (false positive) or if it was a duplicate of another incident. The data value for this status is canceled. An incident is considered cancelled once it’s been determined as a false-positive or it’s been identified as a duplicate of an existing incident. An incident can be progressed to the cancelled status by using the /rootly cancel command or via the Cancel Incident button. The Cancel Incident button is only available when the incident is in the triage status. The data value for the cancelled status is cancelled. When an incident is in the cancelled status, the{{ incident.cancelled_at }} timestamp will be automatically recorded.
