Skip to main content
An alert source is the connection that carries signals from a monitoring, observability, or ticketing tool into Rootly. Nothing else in the Alerts section works until at least one exists: routing rules evaluate alerts from a source, deduplication is configured on a source, and grouping operates on alerts that a source produced. Connecting a source is the first step. Everything else tunes what happens afterwards.
Each source is a distinct connection with its own credentials, deduplication settings, and rate limit. Connecting the same vendor twice — for example one Datadog source per environment — is a valid and common setup.

​
How an Alert Enters Rootly

Understanding the order matters, because most alerting problems are really a problem at one specific stage:
1

A tool fires

Your monitoring tool detects something and sends a payload to Rootly, either through a dedicated integration or a webhook URL.
2

The source receives and identifies it

The alert source parses the payload, maps it to alert fields, and works out whether this is a new alert or another event for one that already exists.
3

Deduplication runs

If the payload matches an open alert on the same source, it is recorded against that alert instead of creating a second one. See Alert Deduplication.
4

A paging target is worked out

If the payload already names a target — a team or service ID — Rootly pages that target directly, without evaluating routes. Otherwise alert routes evaluate the alert and send it to an escalation policy, a team, or a channel — or deliberately nowhere.
5

Grouping and paging follow

Alert grouping can hold related alerts under one page, and the escalation policy takes over from there.
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 rather than downstream.

​
Choosing How to Connect a Tool

Manual paging is not an alert source. A responder paging a teammate ad hoc creates a manual alert with no source behind it — the two paths are separate, which is why manual pages appear even in an organization with no sources connected.
If a dedicated integration exists, use it even if you already have a webhook working. Dedicated integrations map vendor payloads into alert fields, which is what makes routing conditions and deduplication keys straightforward instead of hand-built JSON paths.

​
Supported Sources

Rootly ingests alerts from most monitoring and ticketing tools. Each links to its own setup guide: Alerting and paging platforms — PagerDuty, Opsgenie, Splunk On-Call (VictorOps), PagerTree Observability and monitoring — Datadog, Grafana, New Relic, Prometheus Alertmanager, Honeycomb, Dynatrace, Sentry, Rollbar, Checkly, Chronosphere, Nobl9, Splunk Cloud platforms — AWS CloudWatch, AWS SNS, Google Cloud Monitoring
AWS EventBridge is not an alert source — that integration sends events from Rootly to AWS. To bring EventBridge events into Rootly, route them to an SNS topic subscribed to the AWS SNS source, or use the AWS CloudWatch source for CloudWatch alarms.
Ticketing and work tracking — Jira, ServiceNow, Zendesk Anything else — Generic Webhook Alert Source
This list is not exhaustive, and a tool being absent does not mean it cannot be a source. Anything that can send an HTTP request or an email can become one. Browse the full integrations catalog for everything Rootly connects to.

​
What You Configure on a Source

Beyond credentials, three settings determine how well a source behaves. Getting these right at setup prevents most alerting complaints later.
​
payload path or alert field
What makes two events “the same alert”. Point this at a value the tool sends consistently for the same underlying problem — a monitor ID, a fingerprint, an aggregation key — and repeat events attach to the open alert instead of creating new ones.A key that includes a timestamp, a run ID, or anything else that changes per event silently disables deduplication: every event looks new. Optionally, a regular expression can normalize the value before it is compared. See Alert Deduplication.
​
conditions
How Rootly knows the tool considers the problem over, so the alert can resolve without a human closing it. A rule matches on payload values or alert fields, and can require all conditions or any of them.Auto-resolution needs a reliable way to tie the resolving event back to the original alert — usually the same identifier used for deduplication.
​
payload paths
Which parts of the payload become searchable, routable alert data — service, environment, severity, region, runbook link. Routing and grouping can also read raw payload values by JSONPath, but a mapped field is stable where a JSONPath breaks the moment the vendor reshapes its payload. See Alert Fields.

​
Ownership and Limits

​
team
Each source belongs to a team, and that ownership carries into routing: a team can only build alert routes for sources it owns. Team admins can create routes for their own team only.
​
50 alerts / minute
Applied per source and API key by default, and configurable per team. A source that bursts past it has events rejected rather than queued, so raise the limit for sources you know are spiky.
​
up to 100
A single source can be evaluated by many routes, each with its own conditions. In practice, far fewer and better-scoped routes are easier to reason about than many overlapping ones.

​
Verifying a New Source

Do this before relying on the source in an escalation policy:
1

Send a real test event from the tool

Use the tool’s own test-alert function rather than crafting a payload by hand — you want to see exactly what it sends in production.
2

Confirm the alert appears in Rootly

Check that it was created, and that the title and fields are populated rather than empty or raw JSON.
3

Send the same test twice

The second event should attach to the first rather than create a duplicate. If it creates a second alert, the deduplication key is not stable.
4

Resolve it in the tool

If auto-resolution is configured, the Rootly alert should resolve on its own.
5

Only then attach it to a route

Once ingestion behaves, add the source to an alert route so it starts paging.
Connect and verify a source before adding it to a route that pages a human. A misconfigured deduplication key on a noisy monitor can generate a page per event, which is the fastest way to lose your team’s trust in alerting.

​
Best Practices

  • One source per tool per environment. Separate production from staging so routing conditions stay simple and a staging misfire cannot page production on-call.
  • Fix noise at the source. Deduplication runs before routing, so a stable key removes duplicates before any rule sees them.
  • Map fields you intend to route on, early. Rules can fall back to raw JSONPath, but those break when a vendor reshapes its payload — and adding a field later means revisiting the rules that should have used it.
  • Name sources for what they carry, not for the tool alone. “Datadog — production APM” beats “Datadog 2”.
  • Give spiky sources headroom. Raise the rate limit for sources with known bursts rather than discovering the ceiling during an incident.

​
Troubleshooting

Work outward from Rootly:
  1. Did the tool actually send? Check its own delivery or webhook log first.
  2. Is the endpoint or credential right? A rotated API key is the most common cause of a source that used to work.
  3. Is the source rate limited? Bursts past 50 alerts per minute per source are rejected rather than queued.
  4. Is anything blocking the request? If your egress is restricted, confirm Rootly’s IP ranges are allowed.
The deduplication key is not stable across events. Inspect a raw payload and pick a value that is identical for repeat events — a monitor ID or fingerprint — rather than one containing a timestamp or event ID. See Alert Deduplication.
Either no auto-resolution rule is configured, or the resolving event cannot be matched to the original alert. Confirm the rule’s identifier is the same value used to deduplicate, and that the tool actually sends a resolution event.
Ingestion and paging are separate. Unless the payload names a target directly, an alert reaches someone only through a route — and a source with no matching route creates alerts that page nobody, which is sometimes intentional. Confirm a route includes this source, that its conditions match, and that a paging destination is set. See Alert Routing.
The payload is not being mapped. Dedicated integrations map known vendor payloads automatically; a generic webhook needs the JSON paths configured by hand. See Alert Fields.

Integrations

Per-vendor setup for every tool Rootly connects to.

Alert Routing

Decide who gets paged once alerts are arriving.

Alert Deduplication

Collapse repeat events from the same source.

Alert Fields

Map payload data into routable, searchable fields.

​
Frequently Asked Questions

Yes, and it is often the right setup. A source per environment or per team keeps routing conditions simple and stops a staging alert from reaching production on-call.
Unless their payload names a target directly, they are created and visible in Rootly but page nobody. This is a legitimate configuration for signals you want recorded and searchable without waking anyone.
Existing alerts remain part of the record. Deleting a source stops future ingestion; it does not erase history.
Almost certainly. If it can send an HTTP request, use the Generic Webhook Alert Source; if it can only send email, a source can be given its own inbound address.
Deduplication, because the noise comes from one monitor repeating. Grouping is for one real problem lighting up several unrelated monitors. Alerts compares the two directly.