High-level flow
Monitoring source
-> Integration endpoint
-> Route token and matchers
-> Service resolution
-> Team and rotation or escalation policy
-> Notification channels
-> Alert group and incident historyMain components
| Component | Responsibility |
|---|---|
| Integration endpoints | Receive Alertmanager, Zabbix, Sentry, LibreNMS and webhook payloads. |
| Normalizers | Convert source-specific payloads into consistent alert fields, labels and severity. |
| Routing | Apply route tokens, source checks, matchers, grouping fields and ownership. |
| Services | Attach affected system context, links, runbooks, dependencies and stakeholders. |
| Scheduling | Calculate on-call users from rotations, layers, overrides and escalation policies. |
| Notifications | Deliver incident updates through chat, email, browser push, webhooks and voice providers. |
| Scheduler | Processes reminders, escalations, notification queues and periodic jobs. |
| Database | Stores teams, routes, services, schedules, alerts, alert groups and delivery records. |
Route boundaries
Route intake tokens are intentionally route-scoped. A route defines the source, team, schedule or escalation policy, matchers, grouping behavior and attached channels. This keeps incoming authorization and outgoing delivery configuration separate.
Why alert groups matter
IncidentRelay stores incoming signals as alerts and presents operational work around alert groups. That allows deduplication and grouping to reduce noise while preserving the child alert details needed for investigation.
Operational ownership
Because IncidentRelay is self-hosted, the team operating it owns backups, monitoring, availability, upgrades and network boundaries. That responsibility is the trade-off for keeping incident data and schedules under direct control.