What alert sources are supported?

Every monitoring, error tracking, and ticketing tool incident.io can turn into alerts.

Every alert source maps a monitoring, error tracking, ticketing, or security tool to the same alerting flow: connect it once, and its alerts flow into your routes, escalations, and incidents from then on.

We build and maintain over 40 tool-specific alert sources, listed below, plus generic HTTP, custom HTTP, and email sources that cover everything else. Each one parses that tool’s payload, derives a deduplication key, and maps the payload’s fields onto alert attributes, so you get working alerts without writing a transform.

Can’t find your tool? See Using HTTP or custom HTTP sources below.

Alert source	Setup
AWS CloudWatch	Set up in dashboard
AWS SNS	Set up in dashboard
Azure Monitor	Set up in dashboard
BigPanda	Setup guide
BugSnag	Set up in dashboard
Checkly	Set up in dashboard
Chronosphere	Setup guide
Cloudflare	Set up in dashboard
Coralogix	Set up in dashboard
Cronitor	Set up in dashboard
Dash0	Setup guide
Crowdstrike Falcon	Setup guide
Datadog	Setup guide
Dynatrace	Set up in dashboard
Elastic	Set up in dashboard
Email	Setup guide
Expel	Set up in dashboard
GitHub Issues	Set up in dashboard
Google Cloud Platform	Set up in dashboard
Grafana	Setup guide
Honeycomb	Set up in dashboard
Icinga 2	Setup guide
Jira/ITSM	Set up in dashboard
Monte Carlo	Setup guide
Nagios Core	Setup guide
New Relic	Set up in dashboard
Opsgenie	Set up in dashboard
PagerDuty	Set up in dashboard
Panther	Setup guide
Pingdom	Set up in dashboard
Prometheus Alertmanager	Set up in dashboard
PRTG	Set up in dashboard
Runscope	Set up in dashboard
Sentry Issues	Set up in dashboard
Sentry Metrics	Setup guide
ServiceNow	Setup guide
SolarWinds AppOptics	Setup guide
Splunk	Set up in dashboard
StatusCake	Set up in dashboard
Sumo Logic	Set up in dashboard
Uptime.com	Setup guide
Vercel	Set up in dashboard
Zendesk	Set up in dashboard

Using HTTP or custom HTTP sources

Any tool that can send a webhook can become an alert source, even if it’s not in the list above. Wherever your alerts live, you can start sending them to incident.io.

Default HTTP

Use a default HTTP source when you control the payload, for internal scripts, custom monitors, or anything else that can send JSON shaped to match incident.io’s schema:

Expected body structure

{
  "title": "My first alert",
  "description": "Some additional context",
  "deduplication_key": "first-alert",
  "status": "firing",
  "metadata": {
    "team": "core",
    "service": "api"
  }
}

Use the metadata field to set alert attributes for routing and filtering.

Custom HTTP

Use a custom HTTP source when a tool’s webhook payload can’t be changed to match that schema. Write a JavaScript transform expression that reshapes whatever the tool actually sends into incident.io’s expected format:

Example payload from external tool

{
  "title": "High CPU usage on server-01",
  "status": "firing",
  "description": "CPU usage exceeded 90% threshold",
  "url": "https://monitoring.example.com/alerts/12345",
  "team": "platform",
  "severity": "critical"
}

Your transform expression

// $ represents your incoming payload
return {
  title: $.title ? $.title : 'Custom HTTP alert',
  status: $.status === 'resolved' ? 'resolved' : 'firing',
  description: $.description ? $.description : '',
  source_url: $.url,
  metadata: { team: $.team, severity: $.severity },
};

So you can connect literally anything that speaks webhooks to incident.io, on your own terms, today. See Custom HTTP alert sources for the full walkthrough, including how to power alert attributes and priorities from the transform.

Alert source	Setup
Default HTTP	Set up in dashboard
Custom HTTP	Setup guide

Request an alert source

An HTTP source gets you working straight away, but tell us which tool you’re sending from anyway. Email [e-mail] with the tool’s name and an example payload, and we’ll look at building a native source for it.

Rate limits

Each alert source has its own rate limit. See alert ingestion rate limits for the details and how to split a busy source’s allowance.

Filter incoming alerts

Any alert source can be set to only ingest alerts that match conditions you define, so noisy or irrelevant events are dropped before they create alerts, trigger escalations, or page anyone.

To filter incoming alerts:

1. Open the alert source and find Filter incoming alerts
2. Choose Only ingest alerts that match conditions
3. Add the conditions describing the alerts you want to keep
4. Check the alert preview, which marks the recent alerts your conditions would have dropped, then click Save

A few things to know about how filtering behaves:

• Resolve events are never filtered, so a filter can’t leave an alert firing forever.
• Filters apply to updates too. If a firing alert’s events stop matching your conditions, the alert keeps the details it last had.
• If your conditions can’t be evaluated, we ingest the alert rather than risk dropping it.
• Filtered alerts still count toward your source’s rate limit.