Opsgenie end of life: dates, what moves to Jira, and the alternatives worth a look

Opsgenie has a shutdown date. On 5 April 2027 Atlassian turns off access to the product, and any data that has not been moved to Jira Service Management is deleted. That leaves about five months, which is less than it sounds once you count the integrations, schedules and phone settings a team builds up over the years.
This guide covers what Atlassian has announced, what changes if you follow Atlassian's own migration path, and what the realistic alternatives look like. It also asks a question that is easy to skip: which part of Opsgenie do you actually use?
A note on bias: we make Pocket Alert, and it is in this comparison. It is not a full on-call platform, and the section about it says so. Everything about other products comes from their own pricing pages and docs, checked in October 2026. Prices change, so confirm on the vendor's site before you decide.
What Atlassian announced
The dates come from Atlassian's Opsgenie licensing page:
- 4 March 2025: Atlassian announced that Opsgenie would no longer be sold.
- 4 June 2025, end of sale: new customers can no longer buy or sign up for Opsgenie.
- 5 April 2027, end of support: "access to Opsgenie will be shut off, the product will no longer be accessible." The same page says that "any customer data in Opsgenie that has not been moved to Jira Service Management will be deleted."
Until then, existing customers can keep using Opsgenie and can still add seats. Renewals are allowed only "so long as the subscription term concludes before the end of support effective date of April 5, 2027."
Atlassian's answer is that Opsgenie's alerting and on-call features now live in two other products. Its migration guide says they were built "directly into Jira Service Management and Compass", and that "most of your data will be migrated automatically." Jira Service Management (JSM) is the service desk and ITSM product. Compass is Atlassian's developer portal and software catalog, which now includes alerting and on-call.
What changes if you migrate inside Atlassian
Most of the day-to-day setup carries over: alerts, on-call schedules, escalation policies, routing. The details are in Atlassian's feature changes and deprecations page and its integration changes page. These are the items most likely to need work:
- Integrations. "While most integrations are automatically synced, some require manual setup, and others are no longer supported." Slack, Microsoft Teams and Zoom have to be re-authenticated, and GitLab must be set up again.
- The REST API and API keys. Endpoints have to be updated to the Jira Service Management API, and Opsgenie API key management is replaced by Atlassian authentication. Every script that calls the Opsgenie API directly is on your list.
- On-prem connectors. Opsgenie Edge Connector (OEC) setups must be reconfigured as Jira Edge Connector (JEC).
- Phone numbers. Atlassian-owned numbers used for incoming call routing must be ported manually before migration.
- Old feature versions. Groups become teams (automatically, if you don't convert them first). Global notification policies and heartbeats move to team-based versions, and that conversion is manual. Heartbeats referenced by email address need the new email domain.
- Retired features. The Incident Command Center, stakeholder SMS notifications, team activity streams and Opsgenie-to-Opsgenie sub-accounts are not carried forward.
- The phone app. Contact methods sync over, but responders have to install the Jira mobile app and update their notification settings.
None of this is unusual, but "stay with Atlassian" still means touching every integration and every phone, so it is a fair moment to compare.
First, decide which half of Opsgenie you use
Opsgenie does two different jobs, and teams often need only one of them.
On-call management. Schedules and rotations, overrides, escalation policies ("if nobody acknowledges in 5 minutes, page the secondary, then the manager"), acknowledgement tracking, phone calls and SMS, reporting on who got woken up how often. If several people share a rotation, you need all of this, and the realistic candidates are full incident platforms.
Making the right alert loud on the right phone. One person or a few people, no formal rotation. What they used Opsgenie for was a mobile app that rang through Do Not Disturb for a P1 and stayed quiet for a P5. For that job a full on-call platform is more tool, and usually more cost, than needed.
A few questions settle it quickly:
- Does more than one person take turns being on call?
- Do you rely on escalation when the first person does not respond?
- Do you need phone calls or SMS, not only app pushes?
- Does anyone report on acknowledgement times or on-call load?
Several "yes" answers point you to the full platforms below. All "no" answers put you in the second group.
The realistic destinations
Jira Service Management or Compass
The path of least resistance, with a migration tool and the same company behind it. JSM's pricing page lists a Free plan for up to 3 agents that includes "alerts, on-call schedules, and incident template", with routing rules and escalation policies. Paid plans are priced per agent, and heartbeat monitoring sits in Premium. Compass's pricing page lists Standard at $7.67 per user a month with on-call schedules and alert routing, and Premium at $23.96 per user a month with escalation policies, voice notifications and heartbeats (as of October 2026). Compass has a free plan for 3 full users, but its pricing page does not list alerting in it.
Good fit if you already live in Jira or Compass. Less so if you only used Opsgenie for paging and don't want a service desk.
PagerDuty
The long-standing default for on-call. The incident management pricing page lists a Free plan for 5 users with 1 on-call schedule and 1 escalation policy, and "Free plan accounts receive 100 free global SMS or phone notifications per month." Professional is $21 per user a month billed annually or $25 monthly (as of October 2026). The iOS app can deliver high-urgency pushes as Critical Alerts that get through Focus and silent mode.
Good fit for teams that want a mature, widely integrated on-call product and expect to grow into it.
incident.io
Incident response built around Slack and Microsoft Teams, with on-call as part of the product or on its own. The pricing page lists a free Basic plan with single-team on-call and one schedule, Team at $15 per user a month annually ($19 monthly) plus $10 for on-call, Pro at $25 plus $20 for on-call, and on-call only at $20 per user a month (as of October 2026). Notifications go by app, phone, SMS, Slack, email and WhatsApp, and each notification rule can bypass Do Not Disturb.
Good fit for teams that run incidents in chat and want schedules, escalation and the incident process in one place.
Better Stack
Uptime monitoring, status pages and on-call in one product. The pricing page has a free plan with 10 monitors and heartbeats, a status page and Slack and email alerts. On-call needs a Responder license at $29 a month billed yearly or $34 monthly, which includes "on-call, monitoring and status pages, with unlimited phone call and SMS alerts" (as of October 2026). The mobile app's critical alerts sound through silent mode and Do Not Disturb.
Good fit if you want monitoring and paging from the same vendor, and for small teams that pay per responder rather than per seat.
Grafana Cloud IRM, and what happened to Grafana OnCall OSS
If you planned to self-host Grafana OnCall instead: the open-source project entered maintenance mode on 11 March 2025 and was archived on 24 March 2026, according to its README; the GitHub repository has been read-only since June 2026. Grafana now points users to Grafana Cloud IRM. Its pricing page lists a free tier of 3 active IRM users a month, and Pro with a $19 monthly platform fee that covers 3 active users, then from $20 per active IRM user (as of October 2026). IRM supports phone and SMS, and its mobile app has "Important" notifications that can override Do Not Disturb.
Good fit if your alerts already come from Grafana and Prometheus.
Rootly
Incident response and on-call, with Opsgenie migration listed as a supported service. The pricing page lists On-Call and Incident Response at $20 per user a month each, with no free plan, a startup discount of up to 50%, and two-week trials (as of October 2026). Its feature table includes SMS, voice, push and DND bypass.
Good fit for teams that want a dedicated incident tool with help moving off Opsgenie.
Pocket Alert
A push notification service: an API, inbound webhooks and apps for iPhone and Android. It is not an on-call platform. It has no schedules, no rotations, no escalation policies and no acknowledgement tracking, and there are no team accounts: one account sends to the devices registered on it. If a 20-person rotation is what you are replacing, pick one of the products above.
What it does have is the "loud alert on the right phone" half:
- Five priority levels from
silenttocritical.highis time-sensitive and gets through Focus.criticalplays through the silent switch and Do Not Disturb on iPhone and takes over the screen on Android.criticalis a paid feature; on the Free plan it is delivered ashigh. - Inbound webhooks at
https://p4a.me/wh/<slug>, with a message template that pulls fields from any JSON, a default level per webhook, and a log of every call. - Up to three action buttons per push, including
httpbuttons that send a request from the phone. Paid plans only. - Applications to keep services apart, and several devices per account (3 on Starter, 5 on Medium, unlimited on Large).
The Free plan covers 50 messages a day on one device with one webhook. Paid plans are $6, $12 and $25 a month; see pricing.
Good fit for solo developers, homelabs and small teams where whoever gets the alert deals with it.
The comparison at a glance
| Option | Schedules and rotations | Escalations | Phone call / SMS | Push through DND | Free tier | Best for |
|---|---|---|---|---|---|---|
| Jira Service Management | Yes | Yes | Depends on plan | Jira mobile app | 3 agents | Teams already on Jira |
| Compass | Yes (Standard) | Premium | Voice on Premium | Jira mobile app | 3 users, alerting not listed | Teams with a Compass catalog |
| PagerDuty | Yes | Yes | Yes, 100 a month on Free | Yes, iOS Critical Alerts | 5 users, 1 schedule | Growing teams, broad integrations |
| incident.io | Yes | Yes | Yes | Yes, per rule | Basic, 1 schedule | Chat-centric incident response |
| Better Stack | Yes | Yes | Unlimited with Responder | Yes, critical alerts | Monitors only, no on-call | Monitoring and paging together |
| Grafana Cloud IRM | Yes | Yes | Yes | Yes, Important notifications | 3 active users | Grafana and Prometheus shops |
| Rootly | Yes | Yes | Yes | Yes | No, trial only | Dedicated incident tooling |
| Pocket Alert | No | No | No | critical through the silent switch and Do Not Disturb (paid) | 50 messages a day, 1 device | Solo devs, homelabs, small teams |
Moving the alerting half to Pocket Alert
If you are in the second group, the move is mostly about pointing your alert sources at a webhook and getting priorities right. Here is a Prometheus Alertmanager setup, tested with Alertmanager 0.34.2. Grafana and uptime monitors follow the same idea; see the Grafana alerts and uptime monitoring guides.
Map P1 to P5 onto levels
Opsgenie uses five priorities, P1 to P5, with P3 as the default. Pocket Alert has five levels too, so the mapping is one to one:
| Opsgenie | Pocket Alert level | default_level | On the phone |
|---|---|---|---|
| P1 Critical | critical | 2 | Through the silent switch and Do Not Disturb. Paid plans; high on Free. |
| P2 High | high | 1 | Time-sensitive, gets through Focus |
| P3 Moderate | default | 0 | Normal banner and sound |
| P4 Low | low | -1 | Delivered quietly |
| P5 Informational | silent | -2 | In the feed, no sound or vibration |
A Pocket Alert webhook takes its level from a top-level level field in the incoming JSON, or else from the webhook's own default. Alertmanager's payload has no such field, so you give each priority its own webhook and set the level there. That takes one webhook per priority you want to sound different, so this setup needs a paid plan: Free has one webhook, Starter has five.
Create the webhooks
You can create webhooks in the console, where you set the name, message template, default level and action buttons. For four webhooks a script is quicker, so here is the P1 webhook created with curl, with jq building the body. Use an API key from API Keys:
PA_KEY='your-api-key'
ACTIONS='[
{"type": "http", "label": "Acknowledge",
"value": "{\"url\":\"https://ops.example.com/ack/%alerts.0.fingerprint%\",\"method\":\"POST\"}"},
{"type": "view", "label": "Runbook", "value": "%commonAnnotations.runbook_url%"}
]'
jq -n --arg actions "$ACTIONS" '{
name: "Alertmanager P1",
message: "[%status%] %commonLabels.alertname% on %commonLabels.instance%\n%commonAnnotations.summary%",
default_level: 2,
actions: $actions
}' | curl -s https://api.pocketalert.app/v1/webhooks \
-H "Token: $PA_KEY" -H 'Content-Type: application/json' -d @-
The response contains a url slug. Your receive address is https://p4a.me/wh/ followed by that slug. Repeat with default_level set to 1, 0 and -1 for P2, P3 and P4/P5, and leave out actions where you don't want buttons. P4 and P5 share a webhook here, so P5 arrives as low; give it its own webhook at -2 if you want it silent.
For a firing P1 alert, the push reads:
[firing] HighErrorRate on api-1:8080
5xx rate above 5% for 10 minutes
The title is the webhook's name, prefixed with "Webhook". The %path% placeholders read fields from Alertmanager's JSON, and commonLabels only contains labels that every alert in the group shares, so keep group_by narrow if you rely on instance.
The same applies to the Runbook button. If an alert has no runbook_url annotation, or the alerts in a group have different ones, its value comes out empty. Pocket Alert then drops the Runbook button from that push and keeps Acknowledge.
About that Acknowledge button
The http button sends POST https://ops.example.com/ack/<fingerprint> straight from the phone, without opening the app. Pocket Alert does not record that you tapped it and does not stop anything from happening next. What the button does is up to the endpoint you point it at: a small handler that creates an Alertmanager silence for that fingerprint, posts in a chat channel, or flips a flag in your own tool. If you need "nobody acknowledged, so call the next person", that is escalation, and Pocket Alert doesn't have it.
Route by priority in Alertmanager
Replace your opsgenie_configs with webhook_configs. If your Opsgenie receiver set priority from a label, route on the same label:
route:
receiver: pocketalert-p3
group_by: ['alertname', 'priority']
routes:
- matchers: ['priority="P1"']
receiver: pocketalert-p1
- matchers: ['priority="P2"']
receiver: pocketalert-p2
- matchers: ['priority=~"P4|P5"']
receiver: pocketalert-p4
receivers:
- name: pocketalert-p1
webhook_configs:
- url: 'https://p4a.me/wh/your-p1-slug'
send_resolved: false
- name: pocketalert-p2
webhook_configs:
- url: 'https://p4a.me/wh/your-p2-slug'
- name: pocketalert-p3
webhook_configs:
- url: 'https://p4a.me/wh/your-p3-slug'
- name: pocketalert-p4
webhook_configs:
- url: 'https://p4a.me/wh/your-p4-slug'
send_resolved: false
send_resolved: false on P1 matters. The level belongs to the webhook, not to the alert's status, so a "resolved" message sent to the P1 webhook arrives as critical too and wakes you a second time to say things are fine. Without it you get [resolved] HighErrorRate on api-1:8080 at full volume. Turn it off for P1. Alertmanager routes can't match on resolved status, so to keep resolutions but make them quiet, use a templated url (Alertmanager 0.31+) that sends resolved groups to a low-level webhook, as shown in the Alertmanager guide.
Check the file with amtool check-config alertmanager.yml and reload Alertmanager.
Test before you cut over
Run both side by side for a week: keep the Opsgenie receivers, add the Pocket Alert ones with continue: true on the routes, and compare what arrives. To test by hand, save an Alertmanager payload and post it (the webhook docs explain the template syntax):
curl -X POST https://p4a.me/wh/your-p1-slug \
-H 'Content-Type: application/json' -d @alert.json
Every call shows up in the webhook's history in the console, with the payload that arrived and the message it produced, so a template that renders empty is easy to spot.
Honest limits of this setup
- One phone ringing is the whole safety net. If you sleep through a
criticalpush, nothing else happens. Register a second device, such as a partner's phone or a tablet on the nightstand, if that worries you. - No phone calls or SMS. Pushes only, through Apple's and Google's push services.
- Critical Alerts on iPhone need a separate permission. If it is turned off in iOS settings,
criticalarrives as time-sensitive: it gets through Focus but not the silent switch. - The Free plan won't run this recipe. It has one webhook, no action buttons, and delivers
criticalashigh. It is fine for trying one source at one level.
FAQ
Can I keep using Opsgenie until April 2027?
Yes, if your subscription term ends before 5 April 2027. After that date the product is shut off and unmigrated data is deleted, so plan the move, and any export of history you want to keep, well before then.
Is Pocket Alert a PagerDuty alternative?
For paging a rotation, no. It has no schedules or escalations. For "my monitoring should ring my phone when it matters", yes, and the push notification services comparison and alternatives pages compare it with other tools that do that job.
If the alerting half is what you need, create a free account, point one alert source at a webhook, and see how it feels before April.