index.md

title	Integrations
description	Incoming alert sources and outgoing notification channels

Integrations

IncidentRelay has two different integration layers. Keep them separate when configuring or troubleshooting the system.

Monitoring system -> Incoming integration -> Route -> Notification channels -> User action

Profile-level browser push is separate from notification channels. Users enable browser/PWA push in Profile, and alerts are delivered to active browser push devices of the assigned user. Read more: Browser Push.

Incoming alert integrations

Incoming integrations create or update alerts in IncidentRelay. They are selected by the route source field and require a route intake token.

Source	Endpoint	Documentation
Alertmanager	POST /api/integrations/alertmanager	Alertmanager
AWS SNS/Cloud watch	POST /api/integrations/aws-sns	AWS SNS/Cloud watch
Grafana	POST /api/integrations/grafana	Grafana
OpenSearch Alerting	POST /api/integrations/opensearch	OpenSearch
Kibana Alerting	POST /api/integrations/kibana	Kibana
Datadog	POST /api/integrations/datadog	Datadog
New Relic	POST /api/integrations/new-relic	New Relic
Azure Monitor	POST /api/integrations/azure-monitor	Azure Monitor
Cloud.ru Cloud Eye / SMN	POST /api/integrations/cloud-ru/<route_id>	Cloud.ru
Nagios	POST /api/integrations/nagios	Nagios
Uptime Kuma	POST /api/integrations/uptime-kuma	Uptime Kuma
RMON	POST /api/integrations/rmon	Grafana
Zabbix	POST /api/integrations/zabbix	Zabbix
Sentry	POST /api/integrations/sentry/<route_id>	Sentry
LibreNMS	POST /api/integrations/librenms	LibreNMS
Generic webhook / PagerDuty Events API v2	POST /api/integrations/webhook	Generic webhook

Route intake tokens belong to routes, not to channels. Create a route first, copy its intake token, and use that token in the monitoring system.

Notification channels

Notification channels deliver alerts after a route has matched an incoming alert.

Channel type	Purpose	Documentation
Mattermost	Chat notifications, optional ACK/Resolve/Shelve buttons, message updates	Mattermost channel
Telegram	Telegram Bot API notifications, optional inline actions	Telegram channel
Email	Sends email to assignee, fallback or fixed recipient	Email channel
Slack	Incoming webhook or Bot API notifications with ACK/Resolve/Shelve actions and updates	Slack channel
Feishu / Lark	Custom bot webhook notifications with optional signature verification	Feishu / Lark channel
Discord	Sends notifications to a Discord webhook	Webhook-based channels
Microsoft Teams	Sends notifications to a Teams webhook	Webhook-based channels
Webhook	Sends notification payloads to a custom HTTP endpoint	Webhook-based channels
Voice call	Calls the assigned user's phone through the globally configured voice provider	Voice call channel

Read the common channel behavior first: Notification channels.

Common setup order

1. Create a group
2. Create users and fill contact fields, such as email, phone, Telegram ID
3. Optional: configure browser push and ask users to enable it in Profile
4. Create a team
5. Create a rotation and assign on-call users
6. Create notification channels
7. Create a route and attach channels
8. Copy the route intake token
9. Configure Alertmanager, Zabbix, or webhook sender
10. Send a test alert
11. Verify notification delivery and ACK/Resolve/Shelve flow

Troubleshooting direction

When an alert does not notify a user through a channel, check the chain in order:

Incoming payload -> route match -> route channels -> channel severity filter -> notifier -> external provider

For browser push, check the profile-level chain instead:

alert assignee -> assignee has active browser push subscription -> service worker/browser notification

If a test channel notification works but real alerts do not, the issue is usually route matching, route-channel binding, severity filtering, missing assignee contact data, or a silence rule.

If the browser push test works but the real alert push does not, check that the alert is assigned to the same user who enabled push in Profile.