Keep PagerDuty Teams in Sync With Google Groups
SyncMyGroup team · October 1, 2026
PagerDuty has two different ideas of "who is on the team", and it's worth separating them before automating anything.
- The on-call schedule says who gets paged right now.
- The PagerDuty Team says who belongs to the group that owns a set of services, escalation policies and schedules.
The first changes every week. The second should change only when someone joins or leaves the team — and that's exactly the list your company already keeps in Google Workspace as sre@, payments-eng@ or platform@. This post covers keeping PagerDuty Teams matched to those Google Groups. For the on-call side (keeping a Slack @oncall handle pointed at whoever is paged), see How to keep a Slack @oncall user group in sync with PagerDuty schedules.
What PagerDuty Teams do (as of 2026)
From PagerDuty's documentation, checked October 2026:
- Teams group escalation policies, users, schedules and services, and "allow you to group and control user access to associated PagerDuty objects".
- Adding an escalation policy to a Team also adds its users, schedules and services to that Team.
- Teams can customize the web and mobile views so people see what's relevant to their Team.
- Teams are public by default; private Teams require Advanced Permissions.
- Team roles such as Responder and Manager control what members can do with the Team's objects.
Plan availability, per PagerDuty's docs and pricing page in October 2026:
| Plan | Teams |
|---|---|
| Free (up to 5 users) | Not included |
| Professional ($21/user/month annual, $25 monthly) | Up to two Teams |
| Business, Digital Operations (Legacy), Enterprise for Incident Management | Unlimited Teams |
So if you're on Professional, plan your Team structure carefully; it's only on the larger plans that "one PagerDuty Team per engineering team" is an option.
Why Team membership drifts
PagerDuty Team membership is usually set up once, when the team adopts PagerDuty, and edited occasionally after that. Meanwhile the real team changes:
- New engineers join and can't see their team's services in the PagerDuty app until someone adds them.
- People move teams and keep Team membership — and the access that comes with their Team role — for services they no longer work on.
- Leavers stay on Teams until someone remembers. Worse, if they're still on a schedule, they're a coverage gap.
- Private Teams make it harder to notice, because non-members can't see them.
The people who keep Google Groups accurate (IT, People Ops, managers) usually don't have PagerDuty admin access, and the people who do have it are busy with incidents. Syncing from Google closes that gap.
Option 1: Terraform
If you manage PagerDuty with Terraform, the PagerDuty provider has pagerduty_team and pagerduty_team_membership resources:
resource "pagerduty_team" "payments" {
name = "Payments"
}
resource "pagerduty_team_membership" "payments" {
for_each = toset(var.payments_user_ids)
team_id = pagerduty_team.payments.id
user_id = each.value
role = "responder"
}
That gives you reviewable changes. You still need something to turn payments-eng@acme.com into a list of PagerDuty user IDs and keep var.payments_user_ids current — a pre-step that reads the Google Group through the Admin SDK Directory API, expands nested groups, and maps emails to PagerDuty users. Then someone has to run it.
Option 2: A script against the REST API
PagerDuty's REST API has endpoints to list a Team's members and to add or remove a user from a Team. A reconciliation script looks like every other group sync: read the Google Group, read the Team, map by email, add what's missing, remove what's extra, skip a list of permanent members.
Things to plan for:
- Users must exist. You add existing PagerDuty users to Teams. Decide whether your script is also allowed to create PagerDuty users — on per-user pricing, that's a licensing decision, not just a technical one.
- Removals and schedules. Removing someone from a Team doesn't reassign their on-call shifts. Make sure the leaver flow reassigns shifts before removing them.
- Roles. Decide what Team role new members get, and whether the script should ever change an existing member's role.
- Ownership and alerting, as with any cron job.
Option 3: A purpose-built sync
SyncMyGroup supports Google Groups as a source and PagerDuty teams as a destination, in either direction. Setup:
- Connect Google Workspace and PagerDuty at app.syncmygroup.com.
- Create a sync from
payments-eng@acme.comto the Payments Team. A missing Team can be created; a Team can be removed when its source group is deleted. - Nested Google Groups are supported, so
engineering@with sub-groups resolves to the right people. - Filters and exclusions. Keep all-company groups out of discovery and exclude individuals, such as people on leave.
- Permanent users. Keep an incident commander or an engineering manager on a Team regardless of the Google roster.
- Preview. See every add and remove before anything changes. Because PagerDuty is priced per user, look closely at the additions — the preview tells you exactly who would be added before any seat is affected.
- Notifications.
@SyncMyGroups subscribe <team>in Slack or Microsoft Teams posts each add and remove as it happens.
Sync both ways is useful here too. Some SRE teams treat the PagerDuty Team as the source and want a matching sre-team@ mailing list for incident reviews and calendar invites; that's a PagerDuty → Google sync.
Wiring it into the rest of the incident stack
A Google Group per team can drive the whole incident toolchain:
| Source | Destination | Purpose |
|---|---|---|
payments-eng@ | PagerDuty Payments Team | Who owns and sees payments services |
| PagerDuty Payments schedule | Slack @oncall-payments | Who gets mentioned right now |
payments-eng@ | Slack #payments-incidents | Where the team coordinates |
payments-eng@ | Jira payments group | Incident follow-up tickets |
GitHub payments team | PagerDuty Payments Team | If GitHub is your source of truth for engineers |
Supported pairs include Slack ↔ PagerDuty, Jira ↔ PagerDuty and GitHub ↔ PagerDuty. The broader pattern is covered in incident response team sync.
Rollout plan
- Map Teams to groups. List every PagerDuty Team and the Google Group that should define it. On Professional's two-Team limit, this list is short.
- Check emails. PagerDuty user emails need to match Google emails.
- Decide on permanent members — managers, incident commanders, integration users.
- Reassign shifts for anyone the preview proposes to remove who is still on a schedule.
- Preview, review with the team lead, activate.
- Subscribe a channel so the SRE or IT team sees every Team change.
Keep onboarding in mind: you may not want new hires added to a PagerDuty Team on day one, before they're ready to shadow. A separate Google Group for "on-call eligible" engineers can be the source instead of the full team list. See Employee onboarding: get new hires into the right groups.
Common mistakes
- Syncing the all-engineering group into every Team. PagerDuty Teams are useful because they're narrow. Map each Team to the smallest Google Group that describes it.
- Treating Team membership as on-call eligibility. Being on the Payments Team means you own payments services; it doesn't mean you should be paged. Keep schedules a deliberate decision.
- Two writers. If Terraform manages
pagerduty_team_membershipfor a Team, don't also point a sync tool at it. Pick one source per Team. - Ignoring email mismatches. A Google alias that differs from the PagerDuty login means that person is silently skipped. Fix the email in one place rather than adding exceptions.
Pricing
SyncMyGroup is free up to 5 users with every integration, and Starter is $2 per user per month with unlimited users (pricing).
FAQ
Which PagerDuty plans include Teams?
As of October 2026, PagerDuty's documentation says Professional plans can create up to two Teams, and Business, Digital Operations (Legacy) and Enterprise for Incident Management support unlimited Teams. The pricing page lists the Free plan (up to 5 users) without Teams.
Is a PagerDuty Team the same as an on-call schedule?
No. A Team groups users, services, schedules and escalation policies and controls access to them. A schedule decides who gets paged when. Sync Team membership from your directory, and sync on-call from the schedule.
Will syncing a Google Group create new PagerDuty users?
Check the preview: it lists every person the sync would add before anything is written. Because PagerDuty is priced per user, decide up front whether people outside PagerDuty today should be added.
What happens to on-call shifts when someone is removed from a Team?
Team membership and schedules are separate. Removing someone from a Team doesn't reassign their shifts, so update schedules first when someone leaves or moves.
Line up your PagerDuty Teams with your Google Groups: start free at app.syncmygroup.com or book a walkthrough.