Sync Opsgenie On-Call to a Slack User Group (and Plan for Opsgenie's End of Support)

If your team runs on-call in Opsgenie, you probably have a Slack handle like @oncall-platform that someone updates by hand every rotation. You probably also have a calendar reminder about Opsgenie going away. This post covers both: how to keep that handle matched to the Opsgenie schedule automatically, and how to make sure the handle doesn't break when you migrate.

The Opsgenie timeline, as announced by Atlassian

Atlassian announced in March 2025 that Opsgenie is being retired as a standalone product. The dates on Atlassian's Opsgenie licensing page (checked September 2026):

Date	What happens
June 4, 2025	End of sale. No new Opsgenie sign-ups or purchases, and no plan upgrades or downgrades.
Until April 5, 2027	Existing customers keep using Opsgenie. Renewals are allowed if the term ends before end of support, and extra seats can still be bought.
April 5, 2027	End of support. Access to Opsgenie is shut off. Data that hasn't been moved to Jira Service Management is deleted.

Atlassian's stated destination is Jira Service Management (JSM), where Opsgenie's alerting and on-call features now live, with an automated process to move data and configuration. Atlassian uses the term "end of support", not "end of life", but the practical meaning is the same: after April 5, 2027 there is no Opsgenie to read schedules from.

That matters for anything you've built on top of Opsgenie's API, including a script that keeps a Slack handle in sync.

What Opsgenie and JSM do natively

Opsgenie's Slack app handles alert notifications and actions, and /genie whoisoncall shows who is on call for each schedule. It tells you the answer; it doesn't update a user group. There is a long-standing public suggestion on Atlassian's tracker (OPSGENIE-573) asking for Opsgenie to manage Slack user groups from on-call data, which is a decent signal that it isn't built in.

JSM's ChatOps (2025 onward) added two related features: you can link an on-call schedule to a keyword alias so that typing the alias in a channel makes the bot tag the current responders, and the bot can post a message when the rotation changes. /jsmops whoisoncall works like the old Opsgenie command. None of these maintain a Slack user group's membership. An alias is a keyword the bot responds to, not a Slack @handle, so it doesn't appear in Slack's mention autocomplete and can't be used where Slack expects a user group, such as a group's default channels.

Slack user groups require a paid plan. The API method that sets membership, usergroups.users.update, replaces the whole member list, rejects an empty list, and won't accept guests or bot users.

Option 1: Script it against the Opsgenie API

Opsgenie's Who-Is-On-Call API returns the current participants of a schedule:

GET https://api.opsgenie.com/v2/schedules/{scheduleId}/on-calls?flat=true
Authorization: GenieKey <api-key>

With flat=true the response contains onCallRecipients, an array of usernames (which in Opsgenie are email addresses). EU accounts use api.eu.opsgenie.com. Pass scheduleIdentifierType=name if you'd rather reference schedules by name.

The rest of the script is the same as any on-call sync:

import os, requests

OG = {"Authorization": f"GenieKey {os.environ['OPSGENIE_KEY']}"}
SL = {"Authorization": f"Bearer {os.environ['SLACK_TOKEN']}"}

def oncall(schedule):
    r = requests.get(
        f"https://api.opsgenie.com/v2/schedules/{schedule}/on-calls",
        params={"flat": "true", "scheduleIdentifierType": "name"}, headers=OG)
    r.raise_for_status()
    return r.json()["data"].get("onCallRecipients", [])

def slack_ids(emails):
    out = []
    for e in emails:
        b = requests.get("https://slack.com/api/users.lookupByEmail",
                         params={"email": e}, headers=SL).json()
        if b.get("ok"):
            out.append(b["user"]["id"])
        else:
            print("no Slack user for", e)
    return out

ids = slack_ids(oncall("platform_schedule"))
if ids:
    requests.post("https://slack.com/api/usergroups.users.update",
                  data={"usergroup": "S0PLATFORM", "users": ",".join(ids)}, headers=SL)

This works today. The problem is the expiry date. Every line that talks to api.opsgenie.com has to be rewritten for JSM before April 2027, and the person who wrote it may not be around to do it. Open-source projects that do this (Slackgenie is one) have the same dependency.

Option 2: A sync that follows you through the migration

SyncMyGroup supports both Opsgenie and JSM Ops on-call and teams as sources, alongside Slack user groups and channels as destinations. That makes the migration a configuration change rather than a rewrite:

1. Today: connect Opsgenie and Slack, create a sync from the Opsgenie schedule to @oncall-platform, and add any permanent members (the team lead, so the group is never empty during coverage gaps).
2. Check the preview. You see who will be added and removed before anything changes in Slack.
3. Subscribe a channel. @SyncMyGroups subscribe <team> posts each add and remove, which works as a handover message for the team channel.
4. After you migrate to JSM: connect JSM Ops, point the same Slack destination at the migrated schedule, and preview again. The Slack handle never changes, so nobody's muscle memory breaks.

Because SyncMyGroup syncs in both directions, you can also run it the other way where that's useful — for example, building an Opsgenie or JSM team from a Slack user group that the team already maintains.

A migration checklist for everything group-shaped

Atlassian's migration process moves Opsgenie data and configuration. What it can't know about is everything outside Opsgenie that depends on Opsgenie's teams and schedules. Before you cut over, inventory these:

1. Slack handles driven by on-call. List every @oncall-* group and how it's maintained today — manual, script, or tool. Each one needs a JSM source after migration.

2. Team rosters. Opsgenie teams are often populated from somewhere: a Google Group, an Entra ID group, or by hand. Decide what the source of truth is for JSM team membership. If it's a Google Group, see Sync Google Groups to Jira and Atlassian groups for the Atlassian side.

3. API scripts and integrations. Search your repos for api.opsgenie.com and GenieKey. Each hit is a dependency with a deadline.

4. Escalation paths that reference people directly. Individuals hard-coded into escalation rules instead of schedules are the ones most likely to be stale. Clean them up before you move them.

5. Leavers still on schedules. A migration is a good moment to diff your Opsgenie team membership against your directory. Anyone who has left but is still on a rotation is a gap waiting to happen; see The offboarding gap.

6. Email matching. Opsgenie usernames, JSM accounts and Slack accounts all need to resolve to the same email address. Fix mismatches before the cutover, not during an incident.

If you're evaluating other on-call tools

Atlassian's recommended path is JSM, but some teams use the end of support as a reason to look at alternatives. Whatever you pick, the group-sync question doesn't go away — the Slack handle still needs a source. SyncMyGroup also supports PagerDuty schedules (Slack ↔ PagerDuty) and the setup is the same; the PagerDuty version is covered in How to keep a Slack @oncall user group in sync with PagerDuty.

Suggested timeline

When	Action
Now	Automate the Slack handles from Opsgenie so they're correct today
Before migrating	Inventory group dependencies (checklist above)
Migration	Move data to JSM with Atlassian's process
Same week	Repoint each Slack handle's source from Opsgenie to JSM Ops, preview, confirm
Well before April 5, 2027	Remove Opsgenie API keys and retire old scripts

Leave a margin. April 5, 2027 is the date access stops, not the date to start.

Pricing

SyncMyGroup is free up to 5 users with every integration and 24x7 Slack support. The Starter plan is $2 per user per month with unlimited users and API access (pricing).

FAQ

When does Opsgenie stop working?

Atlassian's licensing page gives April 5, 2027 as end of support, when access to Opsgenie is shut off and data that hasn't been moved to Jira Service Management is deleted. End of sale was June 4, 2025.

Does Opsgenie have a built-in Slack user group sync?

Not that we could find as of September 2026. The Opsgenie Slack app shows who's on call with /genie whoisoncall, and there's an open public request (OPSGENIE-573) for user group management. Teams use scripts or sync tools.

Does JSM replace the need for a Slack @oncall user group?

Partly. JSM ChatOps can tag current responders when someone types a linked alias and can announce rotation changes. It doesn't maintain a real Slack user group, so features that depend on one — autocomplete, @handle mentions in any channel, user group default channels — still need a sync.

Will my Slack handles break when I migrate?

Only if their source disappears. Any script calling the Opsgenie API will stop working at end of support. If the handle is driven by a sync that supports JSM Ops, you switch the source and keep the same Slack group.

---

Planning the move? Book a walkthrough, or read the setup docs at docs.syncmygroup.com.