Skip to main content
This is a reference for the product’s behaviour, not a walkthrough. It answers “what happens next, and what decided that” — the question you have when an alert did something you did not expect. Each stage links to the page that configures it.

​
The Path

1

Ingestion

A monitoring tool posts to an alert source. The source parses the payload and maps it to alert fields.Alert fields are the stable interface everything downstream prefers. Later stages can also read the raw payload directly by JSONPath — deduplication, routing, grouping, and alert workflows all support it — so an unmapped value is not unusable, just harder to work with and liable to break when the tool changes its payload shape.
2

Deduplication

If the payload matches an open alert on the same source, it is recorded against that alert and the count rises. No second alert, no second page. See Alert Deduplication.Deduplication is configured on the source and runs before routing, so a deduplicated event never reaches a routing rule. That ordering is why noise is best fixed at the source.
3

Routing

If the payload already names a target — a team or service ID — Rootly pages that target directly and skips route evaluation entirely.Otherwise alert routes evaluate the alert. Rootly evaluates every route attached to the source; within each route, rules run top to bottom and the first matching rule in that route wins.First-match-wins is therefore per route, not global — which is why an alert can page several destinations at once. An alert that matches nothing in any route becomes a non-paging alert — recorded, not paged.
4

Grouping

Alert grouping can hold several different monitors firing on one underlying problem under a single leader alert, so only the leader pages.Grouping matches on what the alert was routed to, which is why it runs after routing rather than before.How strictly is a setting on the group. Same route requires alerts to have been routed to the exact same target; any selected route lets alerts routed to any of the chosen targets group together. So two alerts with different destinations can group — but only if the rule was configured to allow it.
5

Urgency and paging

Alert urgency decides how hard Rootly pushes: how aggressively to page, whether notifications are audible or quiet, and which escalation path applies inside or outside working hours.The escalation policy then takes over — levels, delays, and targets, as configured in Escalation Policies.
6

Becoming or joining an incident

An alert is not an incident. It becomes one, or attaches to one, in three ways — see the section below.
Manual pages take a shorter path. A responder paging someone from Web, Slack, or mobile creates an alert with the target they chose and pages immediately, skipping ingestion, source deduplication, routing, and grouping. See Manual Paging.

​
Where an Alert Becomes an Incident

Nothing promotes an alert automatically by default. An alert stays an alert until one of these happens:
This is a design decision worth understanding rather than working around. Most alerts should stay alerts — the ones that need a coordinated response are a small fraction, and auto-promoting everything produces incident volume that means nothing. Write an alert workflow with narrow conditions rather than a broad one.
Once attached, responders move between the incident and its alerts, see how many times each alert fired, and use the alert detail to drive mitigation.

​
Reading a Surprise Backwards

When an alert did something unexpected, the stage list above is a checklist. Work down it:

Alerts Overview

The umbrella page, including the lifecycle summary this expands on.

Alert Routing

Routes, rules, and destinations — the stage most surprises come from.

Alert Workflows

The mechanism that turns an alert into an incident.