> ## Documentation Index > Fetch the complete documentation index at: https://docs.rootly.com/llms.txt > Use this file to discover all available pages before exploring further. # Incident Status > The Incident Status lifecycle — Triage, Started, Mitigated, Resolved, Closed, Cancelled — plus transition rules, timestamp validation, sub-statuses, and the separate Scheduled Maintenance lifecycle. ## Overview The **Status** property defines the lifecycle stage of an incident and governs how it progresses from investigation through closure. Status transitions are validated to preserve chronological and logical integrity — you can't skip from Triage to Resolved, and `mitigated_at` can never precede `started_at`. Status is a **fixed property**: the set of statuses (Triage, Started, Mitigated, Resolved, Closed, Cancelled) is system-defined and can't be customized. If you need additional state inside a status, use [Sub-Statuses](#sub-statuses) (this page) or [Custom Statuses](/configuration/custom-statuses). Scheduled Maintenance incidents follow a separate lifecycle with their own statuses — see [Scheduled Maintenance Statuses](#scheduled-maintenance-statuses) below. *** ## Standard Incident Statuses | Status | Description | Data Value | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | **Triage** | An investigative state used to determine whether an issue should escalate into an active incident. This allows teams to evaluate signals before formally beginning response. Timestamped at `in_triage_at`. | `in_triage` | | **Started** | Marks the official activation of incident response. This is the primary active state during which coordination, mitigation, and communication occur. Timestamped at `started_at`. | `started` | | **Mitigated** | Indicates that user-facing impact has been halted or reduced, but remediation, validation, or cleanup work may still be ongoing. Timestamped at `mitigated_at`, which must be after or equal to `started_at`. | `mitigated` | | **Resolved** | Signifies the completion of active incident response. At this stage, service impact has ended and retrospective processes typically begin. Timestamped at `resolved_at`. | `resolved` | | **Closed** | Optional terminal status (team-configurable) used to mark incidents as fully finalized after review. **Requires the incident to already be in Resolved status.** Timestamped at `closed_at`. | `closed` | | **Cancelled** | Terminal status used for false positives or duplicate incidents. Cancelling prevents further lifecycle progression unless the incident is reopened. Timestamped at `cancelled_at`. | `cancelled` | *** ## Terminal Statuses **Resolved**, **Closed**, and **Cancelled** are terminal statuses. They prevent further lifecycle progression unless the incident is explicitly reopened to **Started**, which restarts active response tracking. Cancellation is for incidents that turn out to be false positives or duplicates — they shouldn't appear in production metrics or status pages. Resolution and closure are for incidents that ran their full course. *** ## Status Transition Rules **Lifecycle Constraints** * Incidents in **Triage** or **Cancelled** cannot transition directly to **Mitigated**, **Resolved**, or **Closed**. * **Closed** can only be reached from **Resolved**. * Terminal statuses (**Resolved**, **Closed**, **Cancelled**) may be reopened to **Started**. The constraints exist because Rootly's metrics and retrospective workflows assume an incident in a terminal status actually ran through active response. Skipping Started would produce nonsense lifecycle durations (e.g., MTTR of zero). *** ## Timestamp Validation Rules **Chronological Integrity** Status timestamps are validated to preserve lifecycle order: * `mitigated_at` ≥ `started_at` * `resolved_at` ≥ `started_at` * `closed_at` ≥ `started_at` If you attempt to set a timestamp that violates this order — for example, backdating `mitigated_at` to before `started_at` — Rootly rejects the change and surfaces a validation error. *** ## Sub-Statuses When enabled via team configuration, statuses may contain **sub-statuses** for more granular tracking within a parent lifecycle stage. For example: * **Started** may include multiple Active sub-statuses (up to 8 per team). * **Resolved** may include structured post-incident stages such as "Retrospective". Sub-statuses let teams enforce structured workflows, capture finer lifecycle detail, and introduce controlled progression within major stages. Workflows that trigger on **Status Updated** fire when the parent status changes, regardless of sub-status transitions — but sub-statuses are available in workflow **run conditions**, so you can write workflows that only fire on a specific sub-status. See [Custom Statuses](/configuration/custom-statuses) for the full sub-status configuration guide. *** ## Scheduled Maintenance Statuses Scheduled Maintenance incidents follow a separate lifecycle from standard incidents. Their statuses describe the state of the maintenance window itself, not a response process. | Status | Description | Data Value | | --------------- | ------------------------------------------------------------------------------------------------------ | ------------- | | **Scheduled** | Indicates that the maintenance window has been planned and formally created but has not yet begun. | `scheduled` | | **In Progress** | Indicates that maintenance work is actively underway. | `in_progress` | | **Completed** | Indicates that maintenance activities have concluded successfully. This is the default terminal state. | `completed` | Scheduled Maintenance incidents cannot use standard incident statuses (Started, Mitigated, Resolved). The separation exists because maintenance windows have different lifecycle requirements than unplanned incidents. For more on when to use Scheduled Maintenance, see [Incident Kind](/configuration/configuration#incident-kind). *** ## Best Practices * **Use Triage for ambiguous signals, not for active incidents.** Triage is the "is this even an incident?" stage. Once a responder commits to active mitigation, move it to Started so the lifecycle clock starts. * **Default to Resolved over Closed for most teams.** Closed adds an extra review step that's only worth the overhead if you have a formal post-incident review gate. If you don't, leave Closed disabled — Resolved is the natural terminal state. * **Reserve Cancelled for false positives.** Don't use Cancelled to "clean up" a real incident that ended up being minor — that incident still belongs in metrics. Cancelled is for incidents that were never real (duplicates, test fires from monitoring tools). * **Use sub-statuses for workflow gating, not for taxonomy.** If you want to label incidents as "Investigating", "Mitigating", "Verifying", sub-statuses are the right tool. If you want to label incidents as "Customer Impact", "Infrastructure", "Security" — that's [Incident Types](/configuration/incident-types) or [Custom Fields](/configuration/custom-fields). * **Reopen instead of re-declaring when an incident recurs.** Reopening preserves the original timeline, action items, and retrospective context. Re-declaring fragments the history into two records. *** ## Troubleshooting By design — incidents in Triage haven't entered active response yet, so resolving them would produce a zero-duration lifecycle. Move the incident to Started first (even briefly), then to Mitigated and Resolved. If the incident was a false positive that never warranted response, Cancel it instead. Status timestamps must follow `started_at` ≤ `mitigated_at` ≤ `resolved_at` ≤ `closed_at`. If you're backdating Mitigated to be earlier than Started, the system blocks the save. Either adjust Started earlier or move Mitigated forward to match the actual order of events. Closed is an optional terminal status controlled by team configuration. If your team hasn't enabled it, Resolved is the only terminal status available. Ask an admin to enable Closed in team settings if you need a two-step Resolved → Closed flow. Working as designed. **Sub-status-only transitions do not emit the Status Updated trigger.** The trigger fires only when the *parent* status changes (e.g., Started → Mitigated). If your incident stays in Started and the sub-status moves from "Investigating" to "Verifying," no Status Updated event is dispatched, and no workflow triggered on Status Updated will run — regardless of what run conditions you add. Run conditions can only *filter* workflows that were already triggered. So an "only run when sub-status is Verifying" condition narrows a Status Updated workflow to just the parent transitions that also happen to land on the Verifying sub-status; it does not create a trigger for later Verifying → some-other-sub-status shifts inside the same parent status. If you need automation on sub-status transitions specifically, the current recommendation is to structure your process so sub-status transitions coincide with meaningful parent-status transitions (making the workflow trigger on the parent change), or to run the automation manually via a Slack command workflow. Reopening to Started overwrites `started_at` to the reopen time. The original `started_at`, `mitigated_at`, and `resolved_at` are preserved in the incident timeline events but not the top-level fields. If you need the original timing for reporting, query the timeline events for the historical status transitions. *** ## Frequently Asked Questions Yes. Terminal statuses (**Resolved**, **Closed**, **Cancelled**) can be reopened to **Started** status. This restarts active response tracking and allows the incident to progress through its lifecycle again. Reopening is useful when: * An incident recurs after resolution * Additional investigation reveals the original resolution was incomplete * A cancelled incident turns out to be a real issue **Resolved** indicates that active incident response has completed and service impact has ended. At this stage, retrospective processes typically begin. **Closed** (when enabled via team configuration) is an optional terminal status used to mark incidents as fully finalized after review. It requires the incident to already be in **Resolved** status and provides a clear distinction between incidents that are resolved but still under review versus incidents that are completely closed. Not all teams use the Closed status. If it's not enabled, **Resolved** serves as the terminal status. Status transitions are validated to preserve logical lifecycle progression. Incidents in **Triage** or **Cancelled** cannot skip directly to **Mitigated**, **Resolved**, or **Closed** because these statuses require the incident to have been actively responded to (i.e., in **Started** status first). To resolve an incident that's in Triage, you must first transition it to **Started**, then proceed through **Mitigated** (optional) to **Resolved**. Rootly validates timestamp relationships to maintain chronological integrity. If you attempt to set `mitigated_at`, `resolved_at`, or `closed_at` to a time before `started_at`, the system will reject the change and display a validation error. Timestamps must follow this order: * `started_at` ≤ `mitigated_at` ≤ `resolved_at` ≤ `closed_at` This ensures incident timelines remain accurate and reportable. Sub-statuses provide granular tracking within parent statuses (like **Started** or **Resolved**) but don't change the fundamental status-based workflow triggers. Workflows that trigger on "Status Updated" will still fire when the parent status changes, regardless of sub-status transitions. However, you can use sub-statuses in workflow **run conditions** to create more specific automation logic. For example, a workflow could run only when an incident is in **Started** status with a specific Active sub-status. Sub-statuses are particularly useful for enforcing sequential workflows within a status. *** ## Related Pages The companion fixed property — controls structural behavior and metrics inclusion. Add custom sub-statuses within Triage, Started, Mitigated, and Resolved. The full lifecycle narrative — detection through retrospective.