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
Three options, not two
Evaluate IncidentRelay when self-hosting is a requirement and your team can own upgrades, backups and notification delivery. Evaluate Grafana Cloud IRM when a managed service and incident response alongside Grafana Cloud observability matter more than operating the on-call backend yourself.
Keeping Grafana OnCall OSS is a maintenance decision. Grafana archived it on March 24, 2026. Existing installations do not simply switch off, but Cloud Connection support has ended, including its OSS mobile push and dependent SMS/phone delivery. This is not a claim that every notification path is broken: Grafana documents alternatives such as your own Twilio setup. Audit the delivery paths you actually use. See the official archival and Cloud Connection notice.
What changes when you choose IncidentRelay?
| Decision | IncidentRelay v2.3.1 | Grafana Cloud IRM |
|---|---|---|
| Operating model | Self-hosted; your team controls deployment and maintains the service. | Managed on-call and incident response within Grafana Cloud. |
| Schedules and alerts | Rotation layers, overrides, escalation policies and On-call Health diagnostics. | Rotations, shifts, overrides, alert grouping, routing and escalation. |
| Incident workflow | Technical AlertGroups and separate operational Incidents; see the boundary below. | Incident declaration, response coordination, timelines and post-incident review. |
| Notification setup | You configure chat, SMTP or voice providers; browser/PWA push is enabled per user. | Cloud-managed notification services and the Grafana mobile app. |
| Investigation context | Keep existing monitoring tools and send their alerts to IR through supported integrations. | Incident response alongside Grafana Cloud metrics, logs and traces. |
Cloud capabilities above follow the Grafana IRM overview. Verify current plan terms and delivery coverage for your organization; this comparison does not assume equal commercial entitlements.
Two boundaries worth testing
In IR 2.3, an AlertGroup owns technical acknowledgement, resolution and escalation. A separate Incident owns an operational workflow, priority and assignee, and can link several AlertGroups. Responders and stakeholders remain AlertGroup-scoped in this release. Do not assume an identical collaboration model. See Incident Management.
Self-hosting IR does not make external delivery self-hosted. Chat services, SMTP relays and voice providers remain dependencies. Browser/PWA push is not the Grafana native mobile app. Check channel requirements and browser push setup on the devices your responders carry.
Migrating from Grafana OnCall OSS
The IR v2.3.1 migration guide describes a public-API importer. It runs in dry-run mode by default and writes a plan and report before you choose to apply changes. It is an OSS migration tool, not a claim of automatic Grafana Cloud IRM migration.
- Supported: users and memberships, teams, supported calendar/web schedules and shifts, overrides, basic escalation chains, integrations and their default routes.
- Manual review: external iCal schedules, monthly recurrence, cross-midnight restrictions, simultaneous multi-user shifts or notifications, and arbitrary Jinja2 or whole-payload regex routing.
- Disabled on import: non-default conditional routes. Grafana whole-payload matching is not equivalent to IR normalized-label matching. Rewrite and test matchers before enabling these routes.
- Not transferred: alert history and masked credentials such as outgoing webhook secrets. Configure notification channels and secrets separately.
Keep state.json for repeatable imports and protect route-secrets.json, which contains the new intake URLs and tokens. Do not put either file in a public repository.
A useful pilot, before changing production webhooks
- Inventory every current notification path, then run the importer in dry-run mode with existing users only. Resolve unexpected warnings; do not accept a lossy schedule conversion just to get a green report.
- Compare a full rotation cycle, timezone boundaries and a planned override. Use On-call Health to look for schedule gaps and missing delivery configuration.
- Replay sanitized examples: a production alert, a duplicate, a resolved event and an alert that should not notify. Check the selected team, service and escalation target.
- Let a test alert go unacknowledged to verify backup escalation. Then acknowledge another and verify that paging stops. Confirm actual delivery on responder devices, not just an HTTP success response.
- Switch one low-risk integration and observe an on-call cycle. Keep the previous endpoint and configuration available for rollback; avoid paging both systems' responders during shadow testing.
Do you have to replace Grafana dashboards?
No. Moving on-call handling is a separate decision from moving monitoring. Grafana Alerting can send alerts to IncidentRelay; dashboards can stay where they are. Start with a test deployment and one alert flow.
Grafana OnCall and Grafana Cloud IRM are Grafana Labs products. IncidentRelay is not affiliated with Grafana Labs.