Comparison by the IncidentRelay team. Documentation reviewed on ; IncidentRelay scope: v2.3.1. This is a documentation-based evaluation, not a performance benchmark or a promise of feature parity.
Quick decision · Capabilities · Migration limits · Pilot checklist
The short answer
Evaluate IncidentRelay when running on-call infrastructure yourself is intentional: you need deployment control, inspectable source and ownership of the alert-routing configuration. Evaluate PagerDuty when a vendor-operated service and its established workflows are more valuable than owning that infrastructure.
Neither choice removes the work of defining ownership, maintaining schedules or testing notifications. With IR, add hosting, upgrades, backups and monitoring of the paging system itself to that responsibility list. Compare those costs with the actual PagerDuty plan and add-ons you would use, not just a headline seat price.
Compare the workflow, not just the feature names
| Decision | IncidentRelay v2.3.1 | PagerDuty |
|---|---|---|
| Operating model | Self-hosted, open-source application. Your team operates the deployment. | Vendor-operated incident management platform. |
| Schedules and escalation | Rotation layers, overrides and escalation policies. Import limitations depend on the source schedule type. | Schedules and escalation policies determine which responder is assigned and notified. |
| Event routing | Global and service orchestration, normalized labels, simulation, replay and shadow mode. | Event Orchestration; advanced capabilities depend on the plan and add-ons. |
| Notifications | Chat, email and voice channels, plus profile-level browser/PWA push. Configure the providers and contacts yourself. | User notification rules with push, phone, Slack, email and SMS delivery paths. |
| Incident model | AlertGroups handle technical paging; separate Incidents coordinate the operational workflow. | Service events create alerts and incidents with assignment, acknowledgement, resolution and a timeline. |
PagerDuty lifecycle and delivery details above follow its Incidents Overview. Validate plan entitlements, provider coverage and the exact integrations you depend on before choosing either system.
What IR's incident model does not imply
IR 2.3 separates technical AlertGroups from operational Incidents. One Incident can link multiple AlertGroups without merging their technical history. Acknowledgement and escalation remain AlertGroup concerns; responders and stakeholders are still AlertGroup-scoped in this release. Read the Incident Management boundary before mapping your existing response process.
Is IR a drop-in replacement for the PagerDuty API?
No. IR accepts PagerDuty Events API v2-compatible alert payloads at /api/integrations/webhook. A sender must support changing the endpoint and use an IR route token as routing_key. Test trigger, acknowledge and resolve with a stable dedup_key.
That compatibility covers alert intake, not the PagerDuty REST API, mobile app, Terraform resources or every integration's behavior. Inventory automation separately. A tool that hard-codes PagerDuty's endpoint may need a different integration or an adapter.
What the PagerDuty importer actually transfers
The IR v2.3.1 migration guide documents a dry-run-first importer using both products' public APIs. Review the report before adding --apply.
- Supported: users, teams, memberships, legacy schedules and layers, daily/weekly restrictions, future overrides, escalation policies, services, webhook routes and active/future maintenance windows.
- Not imported: incident or alert history, Event Orchestrations and Rulesets, V3 shift-based schedules, phone numbers, contact methods and notification rules or channels.
- Lossy mappings: shared schedules and policies are cloned per team; a multi-team service uses its first mapped team; parallel escalation targets become consecutive rules with zero delay after the first target. Review each warning against your intended paging behavior.
- Critical cutover requirement: created routes have no notification channels. An imported service is not ready to page anyone until channels or notification policies are configured and tested.
Keep state.json to resume safely. Protect route-secrets.json and route-switch-map.csv: they contain intake credentials. Rebuild orchestration rules deliberately; similar feature names do not make rule languages interchangeable.
A migration acceptance checklist
- Run a dry-run, inventory unsupported objects and rehearse the import in a non-production IR deployment. Back up IR before applying changes.
- Compare one full on-call cycle, timezone changes, overrides and escalation order. Use On-call Health to find gaps and missing delivery configuration.
- Send a trigger twice with the same deduplication key, then acknowledge and resolve it. Check grouping, ownership and the resulting state, not just the response code.
- Test actual chat, email, push or voice delivery. Leave one alert unacknowledged to exercise escalation, and verify that acknowledgement stops further paging.
- Switch one low-risk service using the cutover CSV and observe an on-call cycle. Keep PagerDuty configuration and a documented sender rollback available until acceptance. Avoid duplicate production paging during the pilot.
When not to migrate yet
Pause if a required schedule cannot be represented, responders depend on an untested mobile or voice workflow, historical records must move with the service, or nobody owns the new deployment. Resolve those gaps before switching senders. A successful import report is not an end-to-end delivery test.
Ready to evaluate? Deploy a test instance and validate one representative service before planning the wider rollout.
PagerDuty is a trademark of PagerDuty, Inc. IncidentRelay is not affiliated with PagerDuty.