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.
Options at a glance · Which path fits? · Migration limits · Pilot checklist
Six paths, different responsibilities
Read each row as a starting point for evaluation, not a ranking. Grafana OnCall OSS and Grafana Cloud IRM are separate options; Opsgenie is an exit decision for existing customers.
| Option | Operating model | When to evaluate it | Check before committing |
|---|---|---|---|
| IncidentRelay v2.3.1 | Open-source, self-hosted. | You want control over alert routing and on-call data in your infrastructure. | Assign owners for availability, backups, upgrades and notification providers. |
| PagerDuty | Managed incident-response platform. | You prefer a hosted responder workflow and do not want to operate the paging application. | Validate required workflows, plan entitlements and notification coverage. |
| Grafana OnCall OSS | Self-hosted; archived on March 24, 2026. | You already run it and need a transition plan. | Cloud Connection support has ended. Inventory notification dependencies before choosing a destination. |
| Grafana Cloud IRM | Managed Grafana Cloud service. | You want a maintained Grafana on-call and incident workflow without running its infrastructure. | Check cloud requirements, migration mapping and the resulting responder workflow. |
| Opsgenie | Existing service scheduled to shut down on April 5, 2027. | You need to choose between an Atlassian migration and a different platform. | Preserve required records and verify the destination before the old service is turned off. |
| Better Stack | Managed monitoring, on-call and incident services. | You want monitoring and response together, or want to retain monitoring while changing on-call. | Treat monitoring, responder workflows and status pages as separate migration decisions. |
Primary sources: PagerDuty incident workflow, Grafana OSS archive and Cloud IRM options, Opsgenie migration announcement, and Better Stack Uptime documentation. The detailed comparisons below cover the caveats behind this summary.
Which path fits your team?
- Deployment control is a requirement: evaluate IR, but include engineering time, recovery drills and provider costs. Self-hosted does not mean maintenance-free.
- You want the application operated for you: shortlist managed platforms and test the exact integrations, delivery channels and plan limits you need.
- You are leaving Opsgenie or Grafana OnCall OSS: put lifecycle deadlines and notification dependencies ahead of optional features.
- Your monitoring already works: keep it during the first pilot. Replacing on-call does not require moving logs, uptime checks or public status pages at the same time.
Migration support is not feature parity
IR v2.3.1 includes configuration migration tools for PagerDuty and Grafana OnCall OSS, not Opsgenie or Better Stack. An importer does not mean every schedule, escalation rule or historical record transfers. Start with the release-specific limitations in the relevant comparison.
Use one acceptance checklist for every option
- Choose one representative team and alert source. Record who owns each system and how to roll back.
- Compare a complete rotation, an override and an escalation when the first responder does not acknowledge.
- Send firing, duplicate and recovery events. Verify routing, grouping and which system owns acknowledgement.
- Confirm delivery on real devices. Test a receiver outage and recovery without assuming retries or two-way state synchronization.
- Compare the total operating cost: subscriptions, retained services, hosting, provider charges and engineering time.
Want to evaluate IR? Start with a test deployment and the On-call Health checks. Move a production source only after your acceptance checks pass.