Opsgenie Is Turned Off in April 2027, and One Clock Is Floating
Two of the three dates are fixed and public. The one that catches teams is the 120-day window that starts the day you migrate, and it only applies if you take Atlassian's own exit.
Opsgenie is not deprioritized or in maintenance mode. It gets turned off. Atlassian stopped selling new accounts and trials on 4 June 2025, and the REST APIs stop answering on 5 April 2027. After that the service is gone and anything you did not migrate is deleted.
That leaves about twenty months, which sounds comfortable and is not, because the technical half of this migration is the small half. Exporting schedules and rebuilding escalation policies is a weekend. Re-pointing forty integrations, retraining people on a new mobile app, and getting a line item approved that did not exist in the budget is a quarter. So the question is not which alternative has the best feature list. It is which one you can be live on before your next renewal at a price you can defend.
Prices below came off the vendor pricing pages on 22 August 2026.
The dates, including the one that floats
The floating window is the part worth getting right, and most write-ups of this shutdown, mine included, have stated it too broadly. Atlassian’s documentation says Opsgenie “will also shut down automatically 120 days after your migration date if you don’t turn it off manually,” and that turning it off “is permanent and CANNOT be undone.” That clock is attached to Atlassian’s own migration path into Jira Service Management. Standing up PagerDuty in parallel does not start it.
So the practical reading splits by destination. If you are taking Atlassian’s exit, you get 120 days of parallel access to validate, and then Opsgenie goes dark whether you are ready or not. If you are leaving for a third party, nothing starts a clock except 5 April 2027, and you should keep Opsgenie live and paging until you have proved the new system catches everything.
Atlassian’s official answer is Jira Service Management, and if you already run JSM for your service desk it is a reasonable default: the alerting, on-call, and incident features live there now, the migration tooling exists, and you add no vendors. Plenty of Opsgenie customers never touched the rest of the Atlassian stack, though. They bought a focused on-call tool that did not care what ticketing system they used. For them, “move to JSM” means adopting a service management product to get on-call back, priced per agent. That is a platform decision wearing a migration costume, and it deserves the same scrutiny as any other option on the list.
What to actually evaluate
Under the marketing, one of these tools does five things: schedules and escalation, alert ingestion with dedup and routing, notification delivery that survives a failed push, incident coordination, and the surrounding surface of status pages, API, Terraform provider, SSO, and compliance attestations.
Every product here does the first one. What separates them is the last two, plus how the bill is shaped.
Keep one number in your head while you shop: count responders, not headcount. Almost every vendor charges per person who is on a rotation or acknowledges alerts, and stakeholders who only watch a status page are free or cheap. A 60-person engineering org might have 18 real responders, and that is the multiplier that decides everything.
PagerDuty, the like-for-like
If you want the smallest behavioral change for the people carrying the pager, this is it. Schedules, escalation policies, and routing map almost one to one onto how Opsgenie worked, the mobile app is the most tested in the category, the integration catalog is the largest, and there is documented migration tooling for bringing schedules and services across.
Where it has pulled ahead is the event intelligence layer that groups related alerts and suppresses transient noise. On a busy platform team that is the difference between one page and forty. The catch is the familiar one: much of it lives a tier up.
Current list pricing is a free plan for up to 5 users that includes 100 international phone and SMS notifications a month, Professional at $21 per user per month on annual billing ($25 monthly), Business at $41 annual ($49 monthly), and a custom Enterprise tier. Notifications past the included allowance are metered.
PagerDuty is the safe choice and usually the most expensive one. At 200 people with auditors, that is defensible. At 25 engineers you feel every seat.
Grafana Cloud IRM, if you are already a Grafana shop
The economics here are unusual enough to check before anything else. IRM bills per monthly active IRM user, meaning someone on a schedule or escalation chain or who acts on an alert group, and the free tier covers 3 active IRM users. Pro is $20 per active IRM user with a $19 monthly platform fee that covers the first three, and Enterprise starts at a $25,000 annual commitment, which tells you plainly who that tier is for.
What you give up is depth. The escalation logic, mobile experience, and integration breadth are not at PagerDuty’s level, and the incident coordination side is younger. Adopting Grafana Cloud purely to get IRM is the same mistake as adopting JSM purely to get on-call.
If you already run Grafana and Prometheus and have a small rotation, though, “the alert that fired the dashboard pages you from the same console, for roughly nothing” is a real option Opsgenie never offered.
incident.io, if your incidents already live in Slack
incident.io came at this from the other end. It began as Slack-native incident response, declaring an incident from a slash command, spinning up a channel, assigning roles, building the timeline, drafting the retro, and then added On-call as a module. So it is an incident tool that added paging rather than an alerting tool that added incident features, and the coordination layer is where the painful hours of an outage actually go.
On-call is a separate paid add-on stacked on the base product, so a responder costs meaningfully more than a single seat price suggests. I could not confirm current per-seat figures from a public page, and this vendor negotiates, so get a quote rather than trusting a number from a comparison post.
Worth picking if your incidents already live in Slack and your retros are inconsistent. Not worth picking purely as an Opsgenie paging replacement, where you would be paying for the half you do not use.
The budget end, with two things that changed
For small teams the per-seat math on PagerDuty gets silly quickly, and this is where the alternatives earn their look. Two updates matter since this was first written.
Better Stack bundles uptime monitoring, on-call, incident management, and status pages, and the line worth noticing is that unlimited phone call alerts are included rather than metered. That is precisely the item that quietly inflates a PagerDuty bill. The trap is the à la carte layer: channel-based incident workflows for Slack or Teams are $9 per responder per month on top, and additional status pages bill separately. Price it with the add-ons you will actually turn on.
Squadcast, which used to be the obvious “Opsgenie but cheaper” answer, is now a SolarWinds product. The acquisition closed in 2025, the old pricing URL redirects into SolarWinds’ observability line, and that page does not serve automated readers, so the per-seat figures that circulate in comparison posts are no longer checkable. The product still exists and may still be the right call. Just be aware you are now buying from a large observability vendor rather than a focused independent one, which changes both the procurement conversation and the odds the product gets folded into a suite you did not want.
Rootly and FireHydrant also pitch hard for Opsgenie refugees and lean toward the coordination side like incident.io. If that is your priority, add one for a third quote.
A checklist that will not blow up at 3am
The order matters more than the steps.
Inventory first, and go wider than the console. Every integration, schedule, escalation policy, and team, plus every place an Opsgenie API key or webhook URL is hardcoded in CI, in Terraform, or in a runbook. That last category is what bites.
Then pick on responders times price before you look at a single feature matrix. That number eliminates options faster than anything else, and it is the number finance will ask for first.
Rebuild schedules and escalations by hand even though the exporters help. Layered rotations, overrides, and timezone behavior deserve a person checking them, because a schedule that is mostly right pages the wrong person on a holiday.
Run both systems in parallel for at least two weeks with critical alerts fanned to each. You are hunting for the alert that does not arrive in the new tool. Silent gaps, not loud ones.
Cut over per team rather than all at once, and let each team live through a real incident before you move the next one. If you are taking the Jira Service Management path, do all of this before you trigger Atlassian’s migration, because that is what starts the 120 days.
Aim to be fully live around six months before your renewal rather than before the shutdown date. That leaves a quarter of slack and a clean exit from any contract overlap.
Where I would land
A tiny team should not pay PagerDuty prices for a three-person rotation. Grafana Cloud IRM if you already run Grafana, Better Stack otherwise.
Ten to forty engineers is Better Stack territory if you want uptime monitoring and status pages on one bill and value unlimited phone alerts, or PagerDuty’s Professional tier if you would rather have the biggest integration catalog and the most tested mobile app and can carry $21 a responder.
A mid-size org with a real incident culture and Slack at the center of it should look hard at incident.io, with the caveat that you are buying two products and should price both.
An enterprise with compliance requirements and a large integration footprint should buy PagerDuty. It is the expensive answer and the safe one, and at that size safe is worth money. If you are already deep in Atlassian, JSM is the no-new-vendor option, priced honestly per agent.
The mistake worth avoiding is drifting into Jira Service Management by default because Atlassian pointed there, without checking whether a focused on-call tool does the job better and cheaper. The forced migration is irritating, and it is also the only free excuse you will get to fix the incident process everyone has been complaining about for two years.
Put your two finalists into a real rotation for a week and watch how each behaves during an actual page. The one that feels boring under pressure is the one to buy.