> ## 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. # Alert Statuses > Understand how alerts progress through their lifecycle in Rootly, including triggered, acknowledged, and resolved states with valid transitions. ## 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. ```mermaid theme={null} stateDiagram-v2 [*] --> open open --> triggered open --> resolved triggered --> triggered: retrigger triggered --> acknowledged triggered --> resolved triggered --> open: paging skipped acknowledged --> triggered: retrigger acknowledged --> resolved acknowledged --> open: paging skipped resolved --> triggered: retrigger resolved --> open: paging skipped ``` *** ## Status Definitions ### **open** The alert is not actively paging a responder. This can be its initial state before a notification target is assigned, or the result of a paging attempt that could not notify any 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 * A paging attempt could not notify any target 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. When a paging attempt cannot notify any target—for example, because the selected escalation policy has no pageable targets—Rootly transitions a non-open alert back to `open` and records a `status_update/open` timeline event. ### **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—for example, ack timeout, forced escalation, manual actions) * `triggered → open` (paging could not notify any target) 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) * `acknowledged → open` (paging could not notify any target) If an acknowledged alert hits **acknowledgement timeout**, Rootly automatically **re-triggers** it and resumes escalation. ### **resolved** A closed state indicating no further action is currently required. Notifications cease and Rootly records `ended_at`; the alert can still be reopened through the transitions below. However, Rootly allows: * `resolved → triggered` (re-open regression, manual retrigger, new escalation) * `resolved → open` (paging could not notify any target) 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: open | To: triggered | To: acknowledged | To: resolved | | ---------------- | ------------------ | ------------- | ---------------- | ------------ | | **open** | — | ✅ | — | ✅ | | **triggered** | ✅ (paging skipped) | ✅ (retrigger) | ✅ | ✅ | | **acknowledged** | ✅ (paging skipped) | ✅ (retrigger) | — | ✅ | | **resolved** | ✅ (paging skipped) | ✅ (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 captures four fields: The status the alert transitioned into. The status the alert transitioned out of. Who performed the action — a responder, an automation, or a system event. Additional context such as the escalation step, ack timeout, grouping rule, or routing origin that produced the transition. 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 two lifecycle timestamps: When the alert began. Taken from the source event when provided; otherwise set when the alert is created. Set when the alert transitions into `resolved`. Cleared whenever the alert leaves `resolved` — including transitions back to `triggered` or `open`. These timestamps power duration metrics — mean time to acknowledge (MTTA), mean time to resolve (MTTR), paging duration, and 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 selected escalation policy may have no pageable targets, or every target may have been skipped * 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 → acknowledgement → resolution → retriggering if needed. *** ## Related Pages Ingestion, deduplication, grouping, and routing — how status transitions fit into the broader alert lifecycle. How Rootly picks a team, service, and escalation policy when an alert enters the open status. Normalized data used to condition status-driven workflows and reporting.