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, 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, triggered, acknowledged, resolved — and what drives each.

Manual Paging

Ad-hoc pages from Web, Slack, 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 increments the existing alert’s counter instead of creating a new one. See Alert Deduplication.
  3. Grouping — if several different monitors are firing on the same underlying incident, they bundle under one leader alert. See Alert Grouping.
  4. Routing — Rootly assigns the alert to a team, one or more services, and an escalation policy. See Alert Routing.
  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, 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 / 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.

​
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.
  • 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 steps — a level can notify a Slack channel directly.
  • Team Alert Broadcast — a team 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 can post every new alert to one workspace-wide channel.
  • 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.
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.
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.

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.