Incident Lifecycle

​

Overview

Rootly models every incident using a sequence of lifecycle stages that reflect how teams actually discover, assess, respond to, and close out operational issues. Each stage corresponds to an incident status, and Rootly automatically records timestamps as incidents progress. These statuses power automation, analytics, retrospectives, and help teams maintain a clean, consistent operational process.

​

Triage

Incidents frequently begin with incomplete or ambiguous signals.
The Triage status is designed for these early situations where something may be wrong, but responders are not yet certain. Entering Triage keeps notifications limited so teams can investigate without alarming broader stakeholders. How to enter Triage:

• When creating an incident, select the Mark as In Triage checkbox
• Or update the status from Slack or the web UI

Data value: in_triage
Timestamp: in_triage_at (only recorded if the incident actually enters Triage)

​

Started

Once responders confirm the issue is real, the incident progresses to the Started status. This is the point where coordinated response begins—roles are assigned, communication channels open, and early hypotheses are formed. How to enter Started:

• Leave Mark as In Triage unchecked during incident creation
• Or move from Triage → Started in the UI or via Slack

Data value: started
Timestamp: started_at

​

Detected (Optional)

Some teams track the moment an issue was first noticed, separate from when response formally began. Data value: detected
Timestamp: detected_at

​

Acknowledged (Optional)

Acknowledgement indicates a specific responder has taken ownership, which pauses escalations and clarifies responsibility even before major status transitions occur. Data value: acknowledged
Timestamp: acknowledged_at

​

Mitigated

An incident becomes Mitigated when the immediate impact has been contained. Users may still be affected, but the issue is no longer actively worsening. This is common when temporary fixes, failovers, or emergency controls are applied. How to enter Mitigated:

• Use the Mitigate button
• Or run /rootly mitigate in Slack

Data value: mitigated
Timestamp: mitigated_at

​

Resolved

An incident is Resolved when the underlying issue has been fixed and service impact is no longer present.
This moment typically triggers stakeholder updates and begins the retrospective process. How to enter Resolved:

• Click Resolve
• Or run /rootly resolve in Slack

Data value: resolved
Timestamp: resolved_at

​

Closed

While Resolved means “the system is fixed,” Closed means “all follow-up work is complete.”
This includes finishing retrospectives, verifying action items, and closing out communications. Data value: closed
Timestamp: closed_at

​

Cancelled

A Cancelled incident represents a false positive or the identification of a duplicate.
It prevents unnecessary responder work and keeps analytics clean. How to enter Cancelled:

• Use the Cancel Incident button
• Or run /rootly cancel
• Available only when the incident is in Triage

Data value: cancelled
Timestamp: cancelled_at

​

Planned Maintenance (Optional)

Rootly can model planned or controlled operational work.
Scheduled incident lifecycle values include:

• planning — defining scope
• scheduled — approved window (scheduled_for, scheduled_until)
• in_progress — work underway
• completed — work finished
• verifying — final checks

This allows scheduled maintenance to be tracked with the same rigor as unplanned incidents.

​

Timeline

Every incident includes a Timeline, which organizes all key moments—status changes, role assignments, workflow actions, Slack updates, alerts, and manual entries—into a coherent narrative.

​

Status Overview

*Optional depending on workflow usage.

​

FAQ