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

# Alert Sources

> An alert source is how a monitoring tool gets signals into Rootly. Connect one before configuring routing, deduplication, or grouping.

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.

<Info>
  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.
</Info>

***

## How an Alert Enters Rootly

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

<Steps>
  <Step title="A tool fires">
    Your monitoring tool detects something and sends a payload to Rootly, either through a dedicated integration or a webhook URL.
  </Step>

  <Step title="The source receives and identifies it">
    The alert source parses the payload, maps it to [alert fields](/alerts/alert-fields), and works out whether this is a new alert or another event for one that already exists.
  </Step>

  <Step title="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](/alerts/alert-deduplication).
  </Step>

  <Step title="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](/alerts/alert-routing) evaluate the alert and send it to an escalation policy, a team, or a channel — or deliberately nowhere.
  </Step>

  <Step title="Grouping and paging follow">
    [Alert grouping](/alerts/alert-grouping) can hold related alerts under one page, and the escalation policy takes over from there.
  </Step>
</Steps>

<Note>
  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.
</Note>

***

## Choosing How to Connect a Tool

| Approach                  | Use when                                                                                                             | Setup                                                                                                   |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| **Dedicated integration** | Rootly has a built-in integration for your tool. Always prefer this — payloads are parsed into alert fields for you. | [Integrations](/integrations/overview)                                                                  |
| **Generic webhook**       | Your tool can send an HTTP webhook but has no dedicated integration. You map payload fields yourself.                | [Generic Webhook Alert Source](/integrations/generic-webhook-alert-source/generic-webhook-alert-source) |
| **Email**                 | The tool can only send email. Rootly gives the source its own inbound address.                                       | Configured on the source                                                                                |
| **API**                   | You are generating alerts from your own code or a script.                                                            | [API reference](/api-reference/overview)                                                                |

<Note>
  [Manual paging](/alerts/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.
</Note>

<Tip>
  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.
</Tip>

***

## Supported Sources

Rootly ingests alerts from most monitoring and ticketing tools. Each links to its own setup guide:

**Alerting and paging platforms** — [PagerDuty](/integrations/pagerduty/pagerduty), [Opsgenie](/integrations/opsgenie), [Splunk On-Call (VictorOps)](/integrations/victor-ops), [PagerTree](/integrations/pager-tree)

**Observability and monitoring** — [Datadog](/integrations/datadog/datadog), [Grafana](/integrations/grafana/grafana), [New Relic](/integrations/new-relic), [Prometheus Alertmanager](/integrations/alertmanager), [Honeycomb](/integrations/honeycomb), [Dynatrace](/integrations/dynatrace), [Sentry](/integrations/sentry/sentry), [Rollbar](/integrations/rollbar), [Checkly](/integrations/checkly), [Chronosphere](/integrations/chronosphere), [Nobl9](/integrations/nobl9), [Splunk](/integrations/splunk)

**Cloud platforms** — [AWS CloudWatch](/integrations/aws-cloudwatch), [AWS SNS](/integrations/aws-sns), [Google Cloud Monitoring](/integrations/google-cloud-monitoring)

<Note>
  [AWS EventBridge](/integrations/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.
</Note>

**Ticketing and work tracking** — [Jira](/integrations/jira/jira), [ServiceNow](/integrations/service-now), [Zendesk](/integrations/zendesk)

**Anything else** — [Generic Webhook Alert Source](/integrations/generic-webhook-alert-source/generic-webhook-alert-source)

<Note>
  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](/integrations/overview) for everything Rootly connects to.
</Note>

***

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

<ParamField path="Deduplication key" type="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](/alerts/alert-deduplication).
</ParamField>

<ParamField path="Auto-resolution rules" type="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.
</ParamField>

<ParamField path="Alert field mapping" type="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](/alerts/alert-fields).
</ParamField>

***

## Ownership and Limits

<ParamField path="Owning team" type="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.
</ParamField>

<ParamField path="Ingestion rate limit" type="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.
</ParamField>

<ParamField path="Routes per source" type="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.
</ParamField>

***

## Verifying a New Source

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Resolve it in the tool">
    If auto-resolution is configured, the Rootly alert should resolve on its own.
  </Step>

  <Step title="Only then attach it to a route">
    Once ingestion behaves, add the source to an [alert route](/alerts/alert-routing) so it starts paging.
  </Step>
</Steps>

<Warning>
  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.
</Warning>

***

## 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

<AccordionGroup>
  <Accordion title="Alerts are not arriving at all" icon="signal-slash">
    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](/integrations/ip-whitelist) are allowed.
  </Accordion>

  <Accordion title="Every event creates a new alert" icon="clone">
    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](/alerts/alert-deduplication).
  </Accordion>

  <Accordion title="Alerts arrive but never resolve" icon="hourglass-half">
    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.
  </Accordion>

  <Accordion title="Alerts arrive but nobody is paged" icon="bell-slash">
    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](/alerts/alert-routing).
  </Accordion>

  <Accordion title="Fields are empty or show raw JSON" icon="code">
    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](/alerts/alert-fields).
  </Accordion>
</AccordionGroup>

***

## Related Resources

<CardGroup cols={2}>
  <Card title="Integrations" icon="puzzle-piece" href="/integrations/overview">
    Per-vendor setup for every tool Rootly connects to.
  </Card>

  <Card title="Alert Routing" icon="route" href="/alerts/alert-routing">
    Decide who gets paged once alerts are arriving.
  </Card>

  <Card title="Alert Deduplication" icon="clone" href="/alerts/alert-deduplication">
    Collapse repeat events from the same source.
  </Card>

  <Card title="Alert Fields" icon="tags" href="/alerts/alert-fields">
    Map payload data into routable, searchable fields.
  </Card>
</CardGroup>

***

## Frequently Asked Questions

<AccordionGroup>
  <Accordion title="Can one tool have several sources?" icon="layer-group">
    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.
  </Accordion>

  <Accordion title="What happens to alerts from a source with no route?" icon="route">
    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.
  </Accordion>

  <Accordion title="Does deleting a source delete its alerts?" icon="trash">
    Existing alerts remain part of the record. Deleting a source stops future ingestion; it does not erase history.
  </Accordion>

  <Accordion title="My tool is not in the list — can I still use it?" icon="puzzle-piece">
    Almost certainly. If it can send an HTTP request, use the [Generic Webhook Alert Source](/integrations/generic-webhook-alert-source/generic-webhook-alert-source); if it can only send email, a source can be given its own inbound address.
  </Accordion>

  <Accordion title="Should deduplication or grouping handle my noisy monitor?" icon="scale-balanced">
    Deduplication, because the noise comes from one monitor repeating. Grouping is for one real problem lighting up several unrelated monitors. [Alerts](/alerts/alerts) compares the two directly.
  </Accordion>
</AccordionGroup>