> ## 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.
# Alerts
> How Rootly ingests, deduplicates, groups, routes, and pages on alerts from your monitoring tools — with entry points to every stage of the alert lifecycle.
export const DedupGroupingWizard = () => {
const [choice, setChoice] = useState(null);
const [isDark, setIsDark] = useState(false);
useEffect(() => {
const check = () => {
const el = document.documentElement;
setIsDark(el.classList.contains("dark") || el.getAttribute("data-theme") === "dark");
};
check();
const obs = new MutationObserver(check);
obs.observe(document.documentElement, {
attributes: true,
attributeFilter: ["class", "data-theme"]
});
return () => obs.disconnect();
}, []);
const palette = isDark ? {
surface: "#161412",
surfaceCard: "#161412",
border: "#4a4741",
textPrimary: "#e7e5e4",
textSecondary: "#a6a09b",
textTertiary: "#87817b",
warnBg: "#3e2308",
warnBorder: "#724712",
warnText: "#f8f8bb",
hoverSurface: "#201d1b",
hoverBorder: "#a88bee",
ringOffset: "#161412",
accentText: "#a88bee",
accentFill: "#7748f6"
} : {
surface: "#fcfbfa",
surfaceCard: "#ffffff",
border: "#dcd9d7",
textPrimary: "#292523",
textSecondary: "#57534d",
textTertiary: "#6c6761",
warnBg: "#fafbd6",
warnBorder: "#f5f299",
warnText: "#7f500c",
hoverSurface: "#f3f3fa",
hoverBorder: "#7748f6",
ringOffset: "#ffffff",
accentText: "#7748f6",
accentFill: "#7748f6"
};
const brandPurple = "#7748f6";
const options = [{
id: "same-monitor",
label: "The same monitor keeps re-firing while the issue is still open",
example: "Datadog 'High CPU on web-01' alarm fires every minute until we mitigate."
}, {
id: "many-monitors",
label: "Multiple different monitors fire on the same underlying incident",
example: "Latency, error rate, and DB-health monitors all trip when a service degrades."
}, {
id: "both",
label: "Both happen — same monitor re-fires AND multiple monitors trip together",
example: "Service is degraded, multiple monitors fire, and each one keeps re-firing."
}, {
id: "silent-repage",
label: "I want guaranteed silent behavior while I'm working on the alert",
example: "Whatever else is true, do not re-page anyone after the first page goes out."
}];
const results = {
"same-monitor": {
tool: "Alert Deduplication",
url: "/alerts/alert-deduplication",
summary: "Configure deduplication on the Alert Source with a stable per-payload key (JSONPath or alert field). Repeat events with the same key stack onto the existing alert instead of creating new ones.",
caveat: "Re-page behavior on duplicates can vary by alert source and the existing alert's state. If you need fully deterministic silence, use Alert Grouping instead — it guarantees silent membership for the duration of the time window."
},
"many-monitors": {
tool: "Alert Grouping",
url: "/alerts/alert-grouping",
summary: "Build an Alert Group keyed on destination (team / service / escalation policy) + a time window + content matching rules. The first matching alert pages on-call; subsequent matching alerts join silently as members.",
caveat: null
},
both: {
tool: "Enable both Deduplication and Alert Grouping",
url: "/alerts/alert-deduplication",
summary: "Configure source-level Deduplication first — it runs before the alert is even created and collapses same-monitor noise. Then layer Alert Grouping on top to handle different-monitor-but-related noise. The two are complementary.",
caveat: "Order matters: dedup runs first (at the source level, before alert creation), then grouping runs on whatever survives. After configuring dedup, set up Alert Grouping next."
},
"silent-repage": {
tool: "Alert Grouping",
url: "/alerts/alert-grouping",
summary: "Grouping guarantees silent membership for the duration of the time window — once the leader alert pages, subsequent matching alerts join the group silently regardless of source state. This is the most deterministic 'don't page me again' behavior.",
caveat: "Deduplication might also work for this, but its re-page behavior depends on the source. Use Grouping when you need a guarantee."
}
};
const scopeClass = "dedup-grouping-wizard";
const hoverCss = `
.${scopeClass} .dgw-choice:hover {
background-color: ${palette.hoverSurface} !important;
border-color: ${palette.hoverBorder} !important;
}
.${scopeClass} .dgw-restart:hover {
background-color: ${palette.hoverSurface} !important;
border-color: ${palette.hoverBorder} !important;
}
.${scopeClass} .dgw-cta:hover {
opacity: 0.9;
}
.${scopeClass} .dgw-focus:focus {
outline: none;
}
.${scopeClass} .dgw-focus:focus-visible {
outline: 2px solid ${brandPurple};
outline-offset: 2px;
}
`;
const cardStyle = {
margin: "1rem 0",
padding: "1.25rem",
borderRadius: "0.5rem",
border: `1px solid ${palette.border}`
};
if (choice) {
const r = results[choice];
if (!r) {
return
We couldn't load a recommendation for that selection. Please start over.
Pick the option closest to your situation — we'll point you at the right tool to configure.
{options.map(opt => )}
;
};
## Overview
An **alert** is Rootly's record of "something needs attention." Alerts arrive **programmatically** from monitoring tools like Datadog, PagerDuty, or Sentry, or **manually** from a responder paging a teammate in Web, Slack, or mobile. Once an alert exists, Rootly deduplicates repeats, groups related alerts together, routes each one to the right team, and pages the on-call responder — every stage is configurable.
Structured attributes extracted from every incoming payload.
Send each alert to the right team, service, or escalation policy.
Set how forcefully an alert pages — high, low, or custom.
Collapse repeat firings of the same monitor into one alert.
Bundle related alerts from different monitors into one page.
Open, deferred, triggered, acknowledged, resolved — and what drives each.
Ad-hoc pages from Web, Slack, or mobile.
Alert when a system stops checking in.
Route inbound phone calls to on-call.
***
## Alert Lifecycle
A **programmatic** alert — one that arrives from a monitoring tool through an Alert Source — moves through seven stages:
1. **Ingestion** — a monitoring tool posts to an Alert Source webhook.
2. **Deduplication** — if the same condition is already firing on an open alert, the request increments the existing alert's counter instead of creating a new one. See **[Alert Deduplication](/alerts/alert-deduplication)**.
3. **Routing** — Rootly determines which teams, services, and escalation policies receive the alert. A route can name any combination of them, and an alert can reach several destinations. See **[Alert Routing](/alerts/alert-routing)**.
4. **Grouping** — if several *different* monitors are firing on the same underlying incident, they bundle under one leader alert. Grouping matches on what the alert was routed to, so it runs after routing, never before. See **[Alert Grouping](/alerts/alert-grouping)**.
5. **Paging** — the escalation policy fires and notifies the on-call responder via mobile push, SMS, phone call, or Slack.
6. **Linkage** — the alert can attach to an incident (automatically via [alert workflows](/workflows/alert-workflows), or manually from the incident view).
7. **Resolution** — the alert closes when the underlying condition clears, either from the monitoring tool's resolution signal or by manual close in Rootly. See **[Alert Statuses](/alerts/alert-statuses)**.
Every stage above is a distinct configuration surface in Rootly. This page is the map — each stage links to its own guide.
**Manual pages take a shorter path.** When a responder pages someone directly from Web / Slack / mobile, Rootly creates the alert with the escalation target the responder picked and pages it immediately. Manual pages skip stages 1–4 — there is no Alert Source, no source-level deduplication, no grouping, and no Alert Route evaluation. See [Manual Paging](/alerts/manual-paging) for the full flow.
***
## Programmatic vs. Manual Alerts
| | **Programmatic** | **Manual** |
| - | - | - |
| **Who creates it** | A monitoring or ticketing tool | A responder |
| **How it arrives** | Alert Source webhook | Web, Slack, or mobile |
| **Typical use** | Datadog monitor fires, PagerDuty incident opens, Zendesk ticket lands | Loop in an SME, escalate to another team, page ad-hoc |
| **Learn more** | [Supported Alert Sources](#supported-alert-sources) | [Manual Paging](/alerts/manual-paging) |
Manual pages page the escalation target the responder picked, so paging, on-call rotation, and acknowledgement work the same way once the escalation policy fires. What differs is *before* the escalation policy: manual pages skip Alert Source dedup, Alert Grouping, and Alert Routes — the responder is choosing the target directly instead of letting a route decide.
***
## Supported Alert Sources
Rootly integrates with many alerting and ticketing tools. Some of the most common:
| Integration | Trigger |
| - | - |
| [PagerDuty](/integrations/pagerduty/pagerduty) | When a PagerDuty incident is created |
| [Opsgenie](/integrations/opsgenie) | When an Opsgenie incident is created |
| [Splunk On-Call](/integrations/victor-ops) (VictorOps) | When a VictorOps incident is created |
| [Datadog](/integrations/datadog/datadog) | When a Datadog alert is triggered |
| [Zendesk](/integrations/zendesk) | When a Zendesk ticket is created (customizable) |
| [Nobl9](/integrations/nobl9) | When an SLO is not satisfied |
| [Sentry](/integrations/sentry/sentry) | When a Sentry alert is triggered |
Additional alert sources include **Asana, ClickUp, Rollbar, Jira, Honeycomb, ServiceNow, Linear, Grafana, Alertmanager, Google Cloud, CloudWatch, Azure, Splunk, Chronosphere, New Relic, GitLab**, and more — usually via a dedicated integration or generic webhooks.
If your provider isn't listed, ingest alerts through **[Generic Webhook Alert Sources](/integrations/generic-webhook-alert-source/generic-webhook-alert-source)**.
Alert ingestion is rate limited to **50 alerts per minute per source/API key** by default. The limit is configurable per team, and higher limits are available for Enterprise customers on request.
***
## Reducing Alert Noise
Rootly ships two complementary noise-reduction tools: **Deduplication** and **Alert Grouping**. They solve different problems and can be enabled together.
### Deduplication vs. Alert Grouping
| | **Deduplication** | **Alert Grouping** |
| - | - | - |
| **The problem it solves** | The same monitor keeps firing while the underlying condition is still bad | Multiple *different* monitors fire on the same underlying incident (latency + error rate + DB health all trip at once) |
| **What it matches on** | A stable unique identifier on the payload (JSONPath or alert field) | Destinations (team / service / escalation policy) + a time window + content-match rules |
| **Scope** | Source-level (per Alert Source, keyed dedupe) or team-level (exact-payload suppression) | Cross-source — a group rule can span monitors from different sources. **Only routed/paging alerts can join a group** |
| **What happens to the new event** | No new alert is created; the existing alert's request count increments and a duplicate event appears on its timeline | A new alert is created and joins the existing alert's group as a *member*; the original alert is the *leader* |
| **Paging behavior** | The original page already went out. Repeat events on an unresolved alert do not re-page in the deduped case — exact re-page behavior depends on the source and the alert's state | The leader pages once. Members join silently. No additional pages while the group's time window is open, regardless of how many member alerts arrive |
| **When the consolidation window ends** | When the existing alert is resolved (the next event with the same key starts a new alert) | When the group's time window expires, OR when the leader alert is resolved |
| **Best for** | *"The same alarm keeps re-firing every minute while the issue is open"* | *"Five monitors lit up on the same outage — page me once, attach the others as context"* |
**Plain-English rule:** If your concern is *one noisy monitor*, use Deduplication. If your concern is *one incident lighting up multiple unrelated monitors*, use Alert Grouping. If your concern is *"stop paging me again while I'm working on it"* and you want the most deterministic behavior, **Alert Grouping is usually the better fit** — it guarantees silent membership for the duration of the time window, whereas deduplication's re-page behavior can vary by source.
You can enable both. Dedup runs first (at the source level, before the alert is created), so a deduped event never reaches grouping. Grouping then handles the surviving alerts.
***
## Linking Alerts to Incidents
Alerts become most useful when tied to incidents. In Rootly, alerts attach to incidents via:
* **Integration mappings and workflows** — e.g., "When a PagerDuty incident is created, attach the alert to the corresponding Rootly incident."
* **Automation logic** — based on service, environment, or alert attributes.
* **Manual linking** — from the incident or alert views.
Once linked, responders can jump from the incident to the underlying alert(s), see how many times each alert fired (via the request count), and use alert details to drive mitigation and follow-up tasks.
***
## Default Notification Settings
Every new user arrives with a set of [notification rules](/on-call/on-call-notifications) that decide how their first page reaches them. Admins set those starting channels for the whole organization, separately for high urgency (the user's audible rule) and low urgency (their quiet rule), so a responder's first shift matches how the team pages.
With nothing configured, a new user starts with email, phone call, and SMS on high urgency and email on low urgency — a first page that rings their phone, tablet, and laptop at the same time.
### Setting the Defaults
From **Alerts**, select the gear icon.
In **Default notification settings**, use the checkbox grid to pick the channels new users start with for **High urgency** and for **Low urgency**.
Save. Every user created from this point on is provisioned with those channels.
### Guardrails
* High and low urgency rules must have at least one channel selected. You cannot set a default that does not have any options selected.
* Defaults are a starting point. Users can change their own channels at any time under **Account Settings → Notifications → On-Call Notifications**.
Defaults describe how users are provisioned, not who gets paged. Routing, escalation policies, and schedules decide that — see [Alert Routing](/alerts/alert-routing) and [Escalation Policies](/on-call/escalation-policies).
***
## Best Practices
* **Choose a stable deduplication key.** Use identifiers like monitor IDs, incident keys, or ticket IDs — avoid full message text or highly variable fields.
* **Start narrow, then broaden.** Begin with conservative dedup rules and relax them as you gain confidence, to avoid accidentally merging unrelated alerts.
* **Link alerts to incidents early.** Use workflows to auto-attach alerts to incidents as soon as they're ingested.
* **Watch the request count.** A high `×N` count on an alert is a strong signal of ongoing or flapping conditions and can inform severity and prioritization.
* **Tune rate limits for noisy environments.** If you know a source can spike, increase the per-source rate limit for that team.
* **Set the notification defaults before onboarding a cohort.** New hires are provisioned once, at creation — deciding the starting channels first saves every one of them from reconfiguring their rules after the first page.
* **Own each Slack channel once.** Multiple broadcasts, escalation-policy steps, and workflows can all target the same channel — pick one owner per channel to avoid duplicate posts.
***
## Troubleshooting
Confirm that **Combine duplicate alerts into one alert** is enabled on the Alert Source and that the **deduplication key path** points to a stable, consistent value. If the key changes between alerts, Rootly treats them as separate alerts.
Often this means deduplication is working as designed. Multiple provider alerts may be mapped to a single Rootly alert, with extra occurrences recorded as **ignored/duplicate requests** on the original alert.
Make sure:
* Deduplication is configured correctly, **or** payload-based suppression is enabled.
* Incoming payloads actually match the configured dedup key or body. If the identifier or body differs, Rootly will create separate alerts instead of incrementing the existing one.
Rootly enforces a per-team, per-source/API key rate limit (default **50 alerts/minute**). For high-throughput environments, increase the **alerts rate limit per minute** in team settings or contact support for higher Enterprise limits.
Two separate notification paths are almost always targeting that channel. Rootly can post an alert to a channel through five independent mechanisms, and each one posts its own message:
* **[Escalation policy](/on-call/escalation-policies) steps** — a level can notify a Slack channel directly.
* **Team Alert Broadcast** — a [team](/managing-teams/configuring-teams) can broadcast every alert routed to it into a channel.
* **Service Alert Broadcast** — each service can broadcast alerts on that service into a channel of its own.
* **Default alerts channel** — the [Slack integration](/integrations/slack/slack) can post every new alert to one workspace-wide channel.
* **[Alert workflows](/workflows/alert-workflows)** — can send Slack messages to any channel.
Check each one against the alert's team, services, and escalation policy. Service broadcasts are the most commonly missed — each service is configured separately, and several services can broadcast into the same shared channel. Once you find the second path, pick one mechanism as the owner of that channel and remove the channel from the others.
New users are provisioned from the organization's [default notification settings](#default-notification-settings), so a default that excludes calls or SMS leaves those channels off for everyone created after it was saved. Check the defaults, then have the user add the channel to their own rules under **Account Settings → Notifications → On-Call Notifications**. A phone number also has to be verified before calls or SMS can be used.
Check:
* The integration is installed and authenticated.
* The mapping points to the right team or alert source.
* The webhook or outbound configuration is using the correct URL.
* The payload contains all required fields for that integration.
Also review integration error logs in Rootly for more details.
***
## Frequently Asked Questions
No. Alerts and incidents are separate concepts — an alert says *"something needs attention,"* an incident is the coordinated response. Use [alert workflows](/workflows/alert-workflows) to automatically create or attach to an incident when an alert meets specific criteria, and let low-signal alerts stay as alerts.
Not necessarily — they solve different problems and are independently useful. If your pain is *one noisy monitor re-firing*, dedup alone is enough. If your pain is *five monitors lighting up on the same outage*, grouping alone is enough. Most large tenants run both. See the comparison table above.
An **Integration** is the broader connection to a third-party tool (Datadog, PagerDuty, Sentry) — it can push data both ways. An **Alert Source** is the specific webhook or ingestion channel used to *bring alerts into Rootly*. One integration usually creates one alert source, but you can configure multiple alert sources per integration if you want separate routing rules per environment or team.
Not directly. Once an alert resolves, a new incoming event that matches the same dedup key starts a **new** alert — the resolved one remains a historical record. If a monitoring tool re-fires immediately after resolution, that's typically a signal the underlying condition wasn't actually cleared.
No. Default notification settings apply to users created after the defaults are saved. Existing responders keep the notification rules they have, and every user can edit their own rules regardless of the default. See [Default Notification Settings](#default-notification-settings).
From the paged responder's perspective, it's identical — same escalation policy behavior, same acknowledgement flow, same routing. The difference is purely at ingestion: manual pages originate from a responder in Web, Slack, or mobile instead of a monitoring tool webhook. See **[Manual Paging](/alerts/manual-paging)**.
***
## Related Pages
The coordinated response — where alerts are triaged and worked on.
The paging rules alerts fire against.
Automate what happens to an alert once it lands.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.
### Setting the Defaults