Opsgenie End of Life: Where Open-Source Alerting Stands in 2026

Atlassian stops supporting Opsgenie on April 5, 2027. New sales ended on June 4, 2025, and data left in the platform after the support date gets deleted. If Icinga pushes alerts into Opsgenie today, that route has an expiry date, and so does every on-call rotation and escalation policy configured there.
This post covers the dates, what Atlassian’s migration path does and does not replace, and what the options look like if you want the alerting layer to stay open-source and self-hosted.

What Happens to Opsgenie, and When

Three dates matter:

• March 4, 2025 – Atlassian announced that Opsgenie would be phased out as a standalone product.
• June 4, 2025 – end of sale. No new purchases or trials. Existing customers can still add seats and renew, but cannot change editions.
• April 5, 2027 – end of support. Platform access ends, and unmigrated data is deleted.

Between the announcement and the shutdown, there are roughly two years. Most of that window has already passed. Atlassian keeps the current guidance in its Opsgenie migration resources.

What Atlassian’s Opsgenie Migration Path Covers

Opsgenie’s alerting and on-call features are being folded into Jira Service Management, with Compass offered for service cataloguing. Atlassian provides a migration tool for moving configuration and data across. For a team already standardized on Atlassian, with Jira in daily use and ITSM processes living there, that is the shortest route and probably the right one.

Atlassian documents what carries over and what does not, and a few of the gaps are worth knowing before you plan rather than during:

• Opsgenie phone numbers do not move. The documented workaround is to transfer the number to Twilio after migration to keep it active.
• Bidirectional integrations need Jira Service Management Premium or Enterprise, or Compass Premium.
• On Compass, MS Teams and Zoom integrations are not supported, and Slack connects to one workspace at a time.
• The Opsgenie-to-Opsgenie integration that managed service providers used for sub-accounts is gone. Child accounts convert to free accounts and need their own migration path.

What the migration does not touch is the layer that generates the alerts in the first place. Jira Service Management receives events. Something still has to check whether a host is reachable, whether a certificate is about to expire, whether a database has stopped responding. If that job currently belongs to Icinga, Nagios, Zabbix, Prometheus, or some combination, it still belongs to you after the migration. The Opsgenie decision is a paging decision, not a monitoring decision.

Worth checking before you plan: how many of your Opsgenie escalation policies encode knowledge that exists nowhere else? Schedules and contact details usually survive an export. The reasoning behind “this alert wakes the storage team, that one waits until morning” often does not.

The Open-Source Options for On-Call Got Thinner

Teams that wanted schedules, rotations, and escalation policies self-hosted rather than bought as a service had a short list of options. It got shorter.

Grafana OnCall OSS entered maintenance mode in March 2025, during which fixes were limited to critical bugs and CVEs scoring 7.0 or higher, and the project was archived on March 24, 2026. The repository is now read-only. The Cloud Connection that OSS installations relied on for mobile push, SMS, and phone notifications was switched off on the same date. Existing deployments keep running and schedules still evaluate, but the paging channels that routed through Grafana Cloud stopped, and Grafana’s own guidance points self-hosted users at Twilio or webhooks for voice and SMS.

So within about a year, one commercial platform announced a shutdown and one open-source project stopped being developed. If you are evaluating this space right now, that context is worth having: the market is consolidating toward hosted incident response, and self-hosted alerting is a smaller field than it was.

If Icinga Sends Your Alerts to Opsgenie Today

The Opsgenie integration we document stops being useful when the platform goes away. There are three directions, and they differ mainly in how much of the stack you want to own:

1. Follow Atlassian to Jira Service Management. Icinga stays the alert source. You re-point the notification command at the new endpoint and rebuild routing on the JSM side.
2. Move paging to another provider. Icinga has integrations with several alerting and on-call services. This keeps the change contained to the notification layer and leaves your monitoring configuration alone.
3. Bring the alerting layer in-house. This is where Icinga Notifications comes in, with a caveat that matters. More on that below.

Icinga as an Opsgenie Alternative: What Works, and What Does Not

Icinga 2 has had notifications from the start. You define users, notification commands, and time-based escalations, which covers email, SMS through a gateway, and chat webhooks. An escalation that pages second level after the first fifteen minutes looks like this:

apply Notification "sms-escalation" to Service {
  import "generic-notification"
  command = "sms-notification"
  users = [ "oncall-2nd-level" ]
  interval = 30m
  times.begin = 15m
  assign where service.vars.criticality == "high"
}

What Icinga 2 never had was on-call scheduling, rotation management, and incident ownership as first-class concepts. You could approximate a rotation with time periods and a lot of discipline. Nobody enjoyed it.

Icinga Notifications is the component that adds those pieces. Schedules built from rotations, with timezone support. Event rules that route by object filter, including custom variables. Incidents you can take responsibility for or subscribe to. Escalations triggered by incident age or severity. Email, Rocket.Chat, and webhook channels out of the box, plus a channel specification for building your own, and a REST API for managing contacts and contact groups.

The caveat: Icinga Notifications is at version 0.2.0, released in February 2026. It has carried a beta label since the first release in 2024, the version numbering is still pre-1.0, and the 0.2.0 announcement invites people to try it out rather than to deploy it. Development is active, and the direction is public. The roadmap names official channels as the next area of work, so that alerts arrive where teams already work, with MS Teams, Slack, and ServiceNow listed as candidates.

What that means in practice: installing it on a test system and reporting what breaks is a reasonable use of the time between now and 2027. Putting it under a live 24/7 rotation is not.

If you need phone calls and a mobile app under a hard deadline, and you do not want to operate that yourself, a hosted provider is the better answer. Icinga will feed it.

Fewer Alerts Beats a Better Paging Tool

A migration is a good moment to ask why the volume is what it is. Most on-call pain is not a routing problem. It is a “the router died and we got 140 tickets” problem, and that is solved upstream in monitoring, not downstream in paging.

Clear Channel, one of the largest out-of-home advertising companies, monitors around 4,300 digital panels and 10,000 hosts across 17 European countries. Two things did the heavy lifting: Apply Rules, which handled 80 to 90 percent of ticket noise automatically, and parent-child host dependencies, so a failed router stops generating a ticket for every panel behind it.

“With Icinga we really appreciate the parent-host thing and that it’s agnostic.” – Roar Amundsen, NOC Lead, CCI Tech Europe

Read the full customer story

Dependencies, acknowledgements, downtimes, and sensible thresholds cost nothing in licence terms and reduce what any paging tool has to deal with. If you are rebuilding the notification layer anyway, do this first. We have written more on why alerts stop being read when there are too many of them.

Next Steps

The Icinga Notifications documentation is at icinga.com/docs, and the source and issue tracker are on GitHub. If you want to see the schedules, event rules, and incident views before installing anything, the Icinga Notifications webinar recording walks through them.
If you are working through an Opsgenie migration with Icinga as the alert source and hit something that does not fit, the community channel is the fastest place to raise it.