Skip to main content

​
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, Microsoft Teams, 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.

Alert Fields

Structured attributes extracted from every incoming payload.

Alert Routing

Send each alert to the right team, service, or escalation policy.

Alert Urgency

Set how forcefully an alert pages — high, low, or custom.

Alert Deduplication

Collapse repeat firings of the same monitor into one alert.

Alert Grouping

Bundle related alerts from different monitors into one page.

Alert Statuses

Open, deferred, triggered, acknowledged, resolved — and what drives each.

Manual Paging

Ad-hoc pages from Web, Slack, Microsoft Teams, or mobile.

Heartbeats

Alert when a system stops checking in.

Live Call Routing

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 is folded into it instead of creating a new one. A keyed match increments that alert’s counter; an exact-body match is ignored without one. See 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.
  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.
  5. Paging — the escalation policy fires and notifies the on-call responder via mobile push, SMS, phone call, Slack, or Microsoft Teams.
  6. Linkage — the alert can attach to an incident (automatically via 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.
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 / Microsoft Teams / 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 for the full flow.

​
Programmatic vs. Manual Alerts

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: 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.
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

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 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.
Alert settings modal showing default notification channels for high urgency and low urgency

An example configuration: mobile push on both urgency levels, with calls and SMS reserved for high urgency

​
Setting the Defaults

1

Open Alert Settings

From Alerts, select the gear icon.
2

Choose the Starting Channels

In Default notification settings, use the checkbox grid to pick the channels new users start with for High urgency and for Low urgency.
3

Save the Settings

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 and 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 or Teams channel once. Escalation-policy steps, the default alerts channel, workflows, and (in Slack) team or service broadcasts 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. Occurrences matched by deduplication key are recorded on the original alert as ignored/duplicate requests; occurrences matched on an identical request body are not recorded at all.
Only keyed deduplication moves the counter. Check that:
  • Combine duplicate alerts into one alert is on for the Alert Source and the deduplication key path is set.
  • Incoming payloads resolve to the same key. If the identifier differs, Rootly creates separate alerts instead of incrementing the existing one.
A repeat suppressed by exact-body matching never increments the counter. See Payload-Based Duplicate Suppression.
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 steps — a level can notify a Slack or Microsoft Teams channel directly.
  • Team Alert Broadcast (Slack only) — a team can broadcast every alert routed to it into a Slack channel.
  • Service Alert Broadcast (Slack only) — each service can broadcast alerts on that service into a Slack channel of its own.
  • Default alerts channel — the Slack and Microsoft Teams integrations can each post every new alert to one channel.
  • Alert workflows — can send Slack or Microsoft Teams 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, 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 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.
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, Microsoft Teams, or mobile instead of a monitoring tool webhook. See Manual Paging.

Incidents

The coordinated response — where alerts are triaged and worked on.

Escalation Policies

The paging rules alerts fire against.

Alert Workflows

Automate what happens to an alert once it lands.