Skip to main content

​
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 (this page) or Custom Statuses.
Scheduled Maintenance incidents follow a separate lifecycle with their own statuses — see Scheduled Maintenance Statuses below.

​
Standard Incident Statuses

StatusDescriptionData Value
TriageAn 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
StartedMarks the official activation of incident response. This is the primary active state during which coordination, mitigation, and communication occur. Timestamped at started_at.started
MitigatedIndicates 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
ResolvedSignifies the completion of active incident response. At this stage, service impact has ended and retrospective processes typically begin. Timestamped at resolved_at.resolved
ClosedOptional 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
CancelledTerminal 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 IntegrityStatus 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 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.
StatusDescriptionData Value
ScheduledIndicates that the maintenance window has been planned and formally created but has not yet begun.scheduled
In ProgressIndicates that maintenance work is actively underway.in_progress
CompletedIndicates 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.

​
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 or 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.

Incident Kind

The companion fixed property — controls structural behavior and metrics inclusion.

Custom Statuses

Add custom sub-statuses within Triage, Started, Mitigated, and Resolved.

Incident Lifecycle

The full lifecycle narrative — detection through retrospective.