> ## 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.
# From Alert to Incident
> What Rootly does between an alert arriving and an incident existing — routing, grouping, urgency, paging, and how an alert becomes or joins an incident.
This is a reference for the product's behavior, 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
A monitoring tool posts to an [alert source](/alerts/alert-sources). The source parses the payload and maps it to [alert fields](/alerts/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.
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](/alerts/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.
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](/alerts/alert-routing) 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.
[Alert grouping](/alerts/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.
[Alert urgency](/alerts/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](/on-call/escalation-policies).
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](/alerts/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:
| Route | What triggers it |
| --------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| [Alert workflows](/workflows/alert-workflows) | A workflow whose conditions the alert matches creates an incident or attaches the alert to one |
| Integration mappings | An external tool's incident maps onto a Rootly incident, carrying the alert with it |
| Manual linking | A responder attaches the alert from the incident or alert view |
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:
| Symptom | Stage to check |
| --------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Nothing arrived at all | Ingestion — did the source receive the payload? |
| The alert exists but nobody was paged | Routing — did it match a rule, or become non-paging? |
| One page for several alerts | Grouping — they routed to the same destination |
| Several pages for what looks like one problem | Grouping — they routed to *different* destinations and the group requires the same route |
| Repeat firings created new alerts | Deduplication — the dedup key is not stable |
| Paged, but quietly, or too late | Urgency, then the escalation policy |
| An incident that should not exist | An alert workflow matched more broadly than intended |
***
## Related Pages
The umbrella page, including the lifecycle summary this expands on.
Routes, rules, and destinations — the stage most surprises come from.
The mechanism that turns an alert into an incident.