Keep Incident Response Groups Current Across PagerDuty, Opsgenie and Slack

During an incident, nobody checks whether a group is accurate. They type @payments-oncall, invite @payments to the incident channel, and page the Payments team in PagerDuty. If any of those lists is wrong, the cost shows up in minutes: someone who left in the spring gets paged, the engineer who joined last month doesn't see the channel, the handle points at last week's on-call.

Incident tooling is good at scheduling and escalation. It's less good at keeping the surrounding groups — rosters, Slack handles, channels — in line with each other. This post maps out the groups involved, the platform changes to plan for in 2026, and how to keep them current.

The four lists behind every incident

Most incident processes depend on four distinct lists. They're often treated as one, which is why they drift.

List	Where it lives	Changes when
Responder roster: who is on the team	PagerDuty team, Opsgenie team, JSM Ops team	Someone joins, leaves or moves team
Current on-call: who is on call right now	PagerDuty schedule, Opsgenie / JSM schedule	Every rotation handoff and override
Mention handle: who gets notified by @team or @team-oncall	Slack user group	Should follow the roster or the on-call
Working space: who is in the team or incident channel	Slack channel	Should follow the roster

The roster changes a few times a month. The on-call changes every handoff. The Slack groups should follow one or the other, automatically.

Platform changes to plan around

Opsgenie is being retired

Atlassian stopped selling Opsgenie on June 4, 2025, and end of support is April 5, 2027. After that date, access ends and any data that hasn't been moved is deleted, according to Atlassian's Opsgenie licensing page. The migration path is Jira Service Management, with Compass as an option for teams that only need alerting and on-call alongside a component catalog.

For groups, two details from Atlassian's migration documentation matter:

• Opsgenie Groups aren't supported after migration. You need to replace them with Opsgenie Teams before migrating so schedules come across properly.
• Team-based on-call schedules in JSM require launching Operations for an Atlassian team first. Schedules without a team still work.

If you're running Opsgenie today, the next eighteen months probably include a period where some teams are on Opsgenie and some on JSM, or where you run Opsgenie and PagerDuty side by side while deciding. That's when the rosters drift fastest.

PagerDuty Teams depend on your plan

PagerDuty's documentation (2026) lists Teams as available on Business, Digital Operations (legacy) and Enterprise for Incident Management plans. Professional plan customers can create up to two Teams, rolled out in phases. If you're on Professional with more than two teams, the roster will have to live elsewhere — a Google Group or Slack user group — and drive PagerDuty schedules and escalation policies indirectly.

A structure that holds up

The pattern that works best is to pick one source for each list and derive everything else from it.

Roster source: a directory group. A Google Group or Entra ID group per team (payments-eng@) is the authoritative list of who is on the team. It's where onboarding and offboarding already happen.

On-call source: the schedule. PagerDuty or Opsgenie / JSM. Nothing else decides who is on call.

From those two sources, everything else is derived:

payments-eng@ (Google Group)
├── PagerDuty team "Payments"
├── Opsgenie / JSM team "Payments"      (during migration)
├── Slack user group  @payments
└── Slack channel     #payments

PagerDuty schedule "Payments Primary"
└── Slack user group  @payments-oncall

When someone joins Payments, they're added to payments-eng@. Everything under it follows. When the rotation hands over, @payments-oncall follows the schedule.

Workflow by workflow

Roster → PagerDuty and Opsgenie teams

Driving incident tool team membership from a Google Group means a new hire can be scheduled as soon as they're added to the team, and a leaver disappears from the team without anyone editing PagerDuty. Our post on syncing PagerDuty teams with Google Groups covers this in detail, and the workflow is at Google Group → PagerDuty.

Two things to check. First, that each person already has a user in the incident tool. Second, after any large removal, the schedules and escalation policies the removed people appear on: those are configured separately from team membership, so review them rather than assuming they follow.

On-call schedule → Slack user group

This is the most valuable sync for incident response. @payments-oncall should always point at whoever the schedule says is on call, including overrides.

• For PagerDuty, see syncing PagerDuty on-call to a Slack user group and the Slack ↔ PagerDuty workflow.
• For Opsgenie and JSM Ops, see syncing Opsgenie on-call to a Slack user group and Slack ↔ Opsgenie.

Slack's usergroups.users.update method replaces a user group's whole membership in one call, which suits on-call well: compute who is on call and write that list. The same documentation notes you can't use it to set an empty membership. If a schedule has a gap, decide in advance what the handle should contain — a fallback person, or the team lead.

Roster → Slack handle and channel

@payments and #payments should both match the roster. Mentions reach the right people, and new joiners are in the channel from day one. Slack guests can't be added to user groups, so contractors on guest accounts will be in the channel but not the handle. Plan for that rather than discovering it during an incident.

PagerDuty ↔ Opsgenie during a migration

If you're moving between incident tools, keeping teams aligned on both sides for the transition saves a lot of confusion about who is reachable where. The PagerDuty ↔ Opsgenie workflow keeps team membership consistent until you switch one off.

Setting it up with SyncMyGroup

SyncMyGroup syncs PagerDuty on-call and teams, Opsgenie / JSM Ops on-call and teams, Slack user groups and channels, and Google Groups and Entra ID groups. A typical incident setup for one team is four sync teams:

1. payments-eng@ → PagerDuty team "Payments"
2. payments-eng@ → Slack user group @payments
3. payments-eng@ → Slack channel #payments
4. PagerDuty "Payments Primary" on-call → Slack user group @payments-oncall

For each one:

• Preview first. Check the add and remove lists. A removal from a PagerDuty team or a channel during business hours is low risk; a wrong @payments-oncall during an incident isn't.
• Pin permanent users. The incident commander rota, the engineering manager who should always be in #payments, and the bots that post alerts into the channel.
• Exclude people who are on the team for visibility but shouldn't be paged.
• Subscribe a channel to changes, so on-call handoffs are visible:

@SyncMyGroups subscribe payments-oncall

The channel then gets a message each time someone is added to or removed from the handle. During an incident, that's a quick way to confirm the handle is current.

Pricing is per synced user: free up to 5 users, then $2/user/month on Starter. See pricing.

Common failure modes

Email mismatches across tools. PagerDuty users created years ago with a personal or old address won't match the Google Group. Review unmatched users after the first sync of each team.

Handles that follow the wrong schedule. With primary and secondary schedules, it's easy to point @team-oncall at the secondary by mistake. Name handles after the schedule they follow: @payments-oncall-primary.

Gaps in the schedule. A schedule with no one on call produces an empty list. Decide on fallback behaviour ahead of time.

Silent failure. An expired token stops a sync, and nothing visibly breaks until the handle is wrong during an incident. Change notifications are the cheapest way to notice: if the ops channel goes quiet at a time when handoffs should be happening, something has stopped.

FAQ

When does Opsgenie stop working?

Atlassian lists April 5, 2027 as the end of support for Opsgenie. Access ends and unmigrated data is deleted after that date. New purchases stopped on June 4, 2025. Jira Service Management is the main migration target.

Should the Slack on-call handle follow the team or the schedule?

The schedule. @team-oncall should contain only whoever is currently on call, including overrides. Use a separate handle, like @team, that follows the roster for everyone else.

Do I need PagerDuty Teams to sync on-call to Slack?

Syncing on-call follows schedules, not teams. Teams matter if you want to sync the roster into PagerDuty. PagerDuty lists Teams on Business and Enterprise plans, with Professional limited to two, as of 2026.

Can I keep PagerDuty and Opsgenie teams in sync during a migration?

Yes. Use one directory group as the source for both, or sync PagerDuty and Opsgenie teams with each other directly, so responders exist on both sides until you switch over.

---

Start with the on-call handle for one team. Connect PagerDuty or Opsgenie and Slack in SyncMyGroup and look at the preview, or book a walkthrough.