You still run Opsgenie. Atlassian shuts it down on April 5, 2027. This post covers the key dates, what happens to your data, the two ways out, and a migration checklist. Use these facts to decide where to move.
Is Opsgenie being discontinued?
Atlassian stopped selling Opsgenie on June 4, 2025 and shuts it down on April 5, 2027. Atlassian states: "All Opsgenie customers are impacted by this announcement." See Atlassian's migration page for details.
Opsgenie has been a mature on-call and alerting tool. It offers schedules, escalation policies, a mobile app, phone and SMS notifications, and many integrations. It fits naturally for teams already on Jira.
Key dates: end of sale and shutdown
Atlassian has already stopped sales and set a hard cutoff for service.
| Date | What happens |
|---|---|
| June 4, 2025 | End of sale. Opsgenie stopped selling to new customers. |
| April 5, 2027 | Shutdown. All Opsgenie customers are impacted. Unmigrated data is deleted. REST APIs stop working. |
| Your migration date + 120 days | Opsgenie turns off automatically if you do not turn it off manually. |
Turning Opsgenie off is permanent and cannot be undone.
Dates checked 2026-09-17.
What happens when Opsgenie shuts down
What gets deleted
Data that has not been moved to Jira Service Management is deleted. If you migrate, the data persists in Jira Service Management. This includes alerts, on-call schedules, escalation policies, incident history, audit logs, and migrated configurations. Anything left behind in Opsgenie is gone.
What keeps working until April 2027
The Opsgenie REST APIs continue to work until April 5, 2027. After that date, or once the service is turned off, access ends. User login stops. The mobile app deactivates. Remaining Opsgenie-specific integrations stop working. Deprecated features, including notification policies, incident rules, and actions, become unavailable.
See what happens when Opsgenie is turned off for the full list of impacts. Plan your migration before the APIs stop.
Why Atlassian is moving Opsgenie customers to Jira Service Management
Atlassian directs Opsgenie customers to Jira Service Management. This path keeps alerts and on-call schedules alongside service management. The move suits teams that already use Jira.
Atlassian mentions a limited-time promotional discount for the migration. Exact pricing is in Opsgenie under Settings > Plan your move, or from the account manager.
Your options: Jira Service Management or another on-call tool
Moving to Jira Service Management
Jira Service Management is the supported migration path. Atlassian moves your alerts, on-call schedules, escalation policies, incident history, audit logs and configurations to Jira Service Management. This keeps on-call inside the Jira ecosystem you already use.
Check your tier before you commit. Voice, SMS and ChatOps are gated to higher tiers. If your team relies on phone or SMS paging, verify that your specific plan includes those channels.
Moving to a different on-call tool
If Jira Service Management does not fit, you can move to a dedicated on-call tool. Compare these factors before choosing:
- Notification channels you need: phone, SMS, Slack, or in-app only.
- Schedule features: rotations, layers, overrides, and follow-the-sun support.
- Escalation policies: ordered levels, wait times, and repeat rules.
- Integration flexibility: whether your monitoring tools can switch by changing a URL and key.
- Pricing model: per user or per organization.
Opsgenie migration checklist
1. Write down what you have
Inventory your current setup before making changes. You need a clear map of what is active. List the following items:
- Schedules and rotations
- Escalation policies
- Teams and users
- Integrations and their API keys
- Heartbeats
- Notification rules
Keep this list handy. You will need it to rebuild everything in the new tool.
2. Rebuild schedules and escalation policies
Recreate your on-call rotations and escalation rules in the new platform. Check that handoff times and timezones match your current setup exactly. A mismatch here causes missed pages.
Whether you can import these settings depends on the tool you choose. Some platforms offer import wizards. Others require manual entry. If you must rebuild by hand, verify each layer and each escalation step against your inventory list.
3. Repoint your monitoring integrations
Many monitoring tools let you change the Opsgenie API URL. If your tool supports setting a custom Opsgenie-compatible URL, you can switch to the new platform by changing the URL and the API key.
Prometheus Alertmanager and Grafana are two common examples. In Alertmanager, the config uses opsgenie_configs with api_url and api_key.
receivers:
- name: on-call
opsgenie_configs:
- api_url: https://oncallalerting.com/
api_key: YOUR_API_KEY
Alertmanager appends v2/alerts to the api_url automatically. Grafana's Opsgenie contact point takes the full URL https://oncallalerting.com/v2/alerts.
Send a test alert after changing the config. Verify it appears in the new system. Do not remove the old integration yet.
4. Replace heartbeats
Opsgenie heartbeat pings are not accepted by OnCallAlerting. Its heartbeats use their own ping URL. Update your cron jobs or monitoring scripts to point to the new URL.
A missed ping opens an incident on the escalation policy. The next ping resolves it. Test the new heartbeat endpoint to ensure it triggers and resolves incidents as expected.
5. Run both tools side by side, then turn Opsgenie off
Keep Opsgenie running until the new tool has paged for real alerts. Do not turn Opsgenie off prematurely. Remember that turning Opsgenie off is permanent and cannot be undone.
Run both tools in parallel for at least one full rotation cycle. Watch for missed pages or duplicate alerts. Once you are confident the new tool handles your load, you can shut down Opsgenie.
Moving from Opsgenie to OnCallAlerting
The fit depends on your notification needs. OnCallAlerting accepts Opsgenie-compatible alerts via URL and key changes, but it does not import your existing configuration.
Alertmanager and Grafana keep their Opsgenie integration. You change the API URL and key. OnCallAlerting tested this with Alertmanager 0.34 and Grafana 13.2. The tool accepts the Opsgenie Alert API at POST /v2/alerts.
You rebuild rosters and escalation policies by hand. There is no import from Opsgenie. You define rotations or layers, follow-the-sun schedules, and substitutions. Escalation policies support 1-10 ordered levels.
Heartbeats need a new ping URL. Opsgenie heartbeat pings are not accepted by OnCallAlerting. You point your cron jobs to the new heartbeat endpoint.
Notifications are Slack and in-app only. This fits on-call during working hours or following the sun. Teams that need phone or SMS paging should pick a tool with it.
The price is $39 a month per organization.
Setup details are in the Opsgenie-compatible intake docs, and you can start a 30-day trial without a card.