Skip to main content

​
Overview

Every alert in Rootly progresses through a well-defined finite state machine (FSM) that dictates how it escalates, notifies responders, synchronizes with alert groups, and ultimately resolves.
Understanding these states ensures predictable behavior across Routing, On-Call Escalation Policies, Alert Grouping, and integrations like Slack. Rootly alerts can be in one of four statuses:
  • open
  • triggered
  • acknowledged
  • resolved
These values are stored on the alert’s canonical status enum. All transitions, notification triggers, and timeline events are governed by Rootly’s internal state machine.
Alert Status State Machine

​
Status Definitions

​
open

The alert has been created but has not yet been assigned a notification target. Typical reasons for an open alert:
  • The alert was ingested but did not match a Routing Rule
  • The alert is a non-paging alert
  • It was created manually without a destination
This status allows two transitions:
  • open → triggered (once a notification target is assigned via routing or manual paging)
  • open → resolved
An alert immediately transitions from open → triggered when Routing assigns a team, service, user, or escalation policy.

​
triggered

The alert is actively paging responders. This is the state where on-call users are notified based on escalation logic. A triggered alert:
  • Sends notifications (SMS, push, phone call, Slack)
  • Can be acknowledged by responders
  • Can be resolved manually or via automation
Allowed transitions:
  • triggered → acknowledged
  • triggered → resolved
  • triggered → triggered (retrigger—e.g., ack timeout, forced escalation, manual actions)
All transitions into triggered create a status_update timeline event.

​
acknowledged

A responder confirmed that they have seen the alert and are working on it. Escalation pauses unless a timeout or retrigger occurs. Allowed transitions:
  • acknowledged → resolved
  • acknowledged → triggered (ack timeout or manual retrigger)
If an acknowledged alert hits acknowledgement timeout, Rootly automatically re-triggers it and resumes escalation.

​
resolved

A terminal state indicating no further action is required. Notifications cease and Rootly records ended_at. However, Rootly allows:
  • resolved → triggered (re-open regression, manual retrigger, new escalation)
This ensures alerts can be reopened without creating duplicates.
Resolved alerts remain visible and analyzable in your alert history, even after re-triggering.

​
Summary Table of Allowed Transitions

From ↓To: triggeredTo: acknowledgedTo: resolved
open✅—✅
triggered—✅✅
acknowledged✅ (retrigger)—✅
resolved✅ (retrigger)——
Retriggering is a first-class action in Rootly. A retrigger transitions an alert back to triggered, restarts escalation, and produces appropriate timeline events.

​
How Rootly Records Status Changes

Every transition writes a status_update event into the alert timeline. A status event includes:
  • The new status
  • The previous status
  • Who performed the action (user or system)
  • Metadata such as escalation step, ack timeout, grouping rule, or routing origin
These timeline entries power audit trails, analytics, and seamless Slack updates.

​
Interaction With Alert Grouping

When an alert is part of an Alert Group, status synchronization is automatic:

​
Leader Alert Behavior

  • The group leader is the first alert in the group (the one that paged).
  • Any change to the leader’s status cascades to all members.
  • Member alerts update timestamps, noise indicators, and events to match the leader.

​
Member Alert Behavior

  • Members never independently influence group state.
  • Status changes come exclusively from the group leader.
  • Retriggering the leader retriggers all members.
This ensures responders never lose the true “source of paging,” even when many alerts represent the same event.

​
Visual Indicators Across Rootly

Rootly uses consistent color/status styling across the Web UI, Slack, and Mobile:
  • 🟥 Open / Triggered — Requires action
  • 🟧 Acknowledged — Someone is actively working the alert
  • 🟩 Resolved — Incident has concluded
These indicators appear in:
  • Alert lists
  • Slack alert threads
  • Alert details
  • Incident sidebars when alerts link to incidents

​
Timestamp Behavior

Each alert automatically manages its own lifecycle timestamps:
  • started_at – Set when the alert is created
  • ended_at – Set when transitioning into resolved
  • ended_at is cleared if later retriggered
This enables clean duration metrics (MTTA, MTTR, paging duration, escalation analytics).

​
Troubleshooting

  • It may not match any routing rules
  • The alert source may not be associated with an Alert Route
  • No notification target was assigned
  • The alert may be a non-paging alert
  • Ensure its status is triggered, not open
  • Validate the routing rule actually assigned a team or escalation policy
  • Confirm notification channels are enabled
  • Check for quiet-only escalation paths
  • Review acknowledgement timeout settings
  • Check whether escalation policies intentionally retrigger
  • Ensure grouping leader logic isn’t retriggering members
This is expected if:
  • A user manually retriggered
  • The system detected a regression
  • A new routing condition matched and assigned a destination

​
Summary

Alert Statuses are the backbone of Rootly’s alerting engine. They define:
  • How and when responders are notified
  • How escalation policies activate
  • How grouping behaves
  • How alerts appear in dashboards and Slack
  • How timeline events reflect real-world activity
By enforcing strict, predictable transitions—and exposing complete audit trails—Rootly ensures smooth, reliable alerting workflows from ingestion → paging → acknowledgment → resolution → retriggering if needed.