How to Remove a User from PagerDuty (3 Methods)

In PagerDuty, an offboarding gap shows up at 3 a.m. A departing engineer who is still on a rotation, or who still holds an open incident, either blocks the delete or leaves an escalation step paging someone who has already gone.

How to remove a user from PagerDuty comes down to that handover, since the delete itself takes one click once schedules, escalation policies, and incidents are clear. Torii’s 2026 SaaS Benchmark report shows how common leftover seats are across SaaS, with about 2.5% of seats in paid apps still assigned to people who have left the company (data from January to December 2025).

Three methods cover the job, starting with PagerDuty’s own Users page for a single departure. Torii then runs the removal inside every offboarding, triggered from your HR system or identity provider, and the PagerDuty REST API handles scripted or bulk cleanup.

How to Remove a User from PagerDuty: Clear the Blockers First

PagerDuty’s Manage Users documentation lists three common reasons a delete fails. Your role lacks permission, the user is still on call (now or in the future) on a schedule or escalation policy (the ordered list of who gets paged when the first responder doesn’t answer), or the user has at least one open incident. Two accounts can’t be deleted at all, your own and the Account Owner’s, so an outgoing Account Owner has to transfer ownership first under Account Settings > Change Account Owner.

How strict those blockers are depends on whether your account has Offboarding, PagerDuty’s guided removal flow. It needs one of the Business, Digital Operations (legacy), or Enterprise for Incident Management plans plus Advanced Permissions. This article calls those accounts “with Offboarding” and every other account “without Offboarding”. With Offboarding, a schedule or escalation policy no longer stops the delete, because, in the words of PagerDuty’s Offboarding guide, “The offboarded user will appear in their old Escalation Policies and Schedules as a placeholder stub.” Open incidents are the exception (see the table).

Source: PagerDuty Docs, Manage Users and Offboarding, checked October 2026.

PagerDuty has no deactivate option to park an account while the handover happens, and if you provision PagerDuty through SCIM, deactivating someone in your identity provider deletes them in PagerDuty. That puts the handover on your offboarding checklist ahead of the identity shutdown. PagerDuty’s SCIM provisioning docs are blunt about it: “PagerDuty does not support deactivating and reactivating the same user.”

Someone changing roles rather than leaving may not need a delete at all. Per PagerDuty’s user roles reference, Stakeholders can view objects but can’t make modifications, and their licenses aren’t billed the same as full users. Annual plans carry separate Full User and Stakeholder limits, shown at the top of People > Users.

Use PagerDuty’s Users Page

The Users page handles a single removal from start to finish, and most of the work sits in the handover steps before you delete a user in PagerDuty. Steps 6 and 7 differ depending on whether your account has Offboarding.

1. Confirm your role can delete users

Only the Admin, Global Admin, and Account Owner base roles can delete users in PagerDuty. Anyone else runs into the permissions blocker above, so hand the removal to someone holding one of those three roles.

2. Open People > Users and the On-Call Shifts tab

Go to People > Users, click the person’s name, and open the On-Call Shifts tab. Their schedules appear on that tab, and the escalation policies they belong to are listed on the left.

3. Hand over schedules and escalation policies

Replace the person in each schedule and escalation policy with whoever takes over their shifts. With Offboarding this can wait, because the flow in step 6 lists the same schedules and policies and lets you remove the user from them there.

4. Reassign or resolve open incidents

Every open incident needs a new owner or a resolution, by hand or in the Offboarding flow, before you continue. The flow handles it with each open incident ticked and set to Reassign to EP or Resolve, but only after the Account Owner switches it on at User Icon > Account Settings > User Offboarding, where the recommended option restarts the incidents on their escalation policy. If the leaver is the only on-call person on that policy, the incident goes to the Account Owner.

5. Click Delete User on the person’s profile

Back on the profile you opened in step 2, click Delete User to start the removal.

6. Confirm, or finish the Offboarding flow

Without Offboarding, PagerDuty asks you to confirm and the account is removed. With Offboarding you land in the Offboarding flow instead, which shows open incidents first and then the user’s escalation policies and schedules. Remove the user from each one yourself, or click Next and PagerDuty emails the Team Managers to fill the gaps (Global Admins and the Account Owner get that email when there’s no team or manager).

7. Replace the placeholder stubs

After an Offboarding-flow deletion, the person’s old spots in schedules and escalation policies hold a placeholder, and banners tell admins to replace it. PagerDuty also emails about the gaps, so put a real responder in each spot before the next shift starts.

These steps take minutes for one person, but they repeat for every leaver, and when nobody owns them the seat stays assigned.

Use Torii to Remove PagerDuty Users in Every Offboarding

Torii’s PagerDuty connector syncs each user’s name, email, status, license, and role, and it runs six workflow actions in PagerDuty, removal among them.

1. Sign up for Torii

Sign up through Torii’s free two-week proof of concept, which sets up the Torii account you’ll connect PagerDuty to.

2. Connect PagerDuty with a read-write API key

In PagerDuty, an Admin or the Account Owner creates a general access REST API key under Integrations > API Access Keys > Create New API Key. Leave the Read-only box unchecked, because a read-only key syncs users but can’t remove anyone. Then open the Integrations page in Torii, click Connect on the PagerDuty tile, and paste the key. A green checkbox appears once the sync finishes, per Torii’s PagerDuty integration guide.

3. View PagerDuty in Torii and automate removal

After the sync, PagerDuty shows up in Torii with every user’s status, role, and license. Torii’s Licenses page lists licenses assigned to past employees as a reason a license is wasted, which puts seats still held by leavers in front of IT.

To make removal automatic, add Remove PagerDuty user from teams, then Remove PagerDuty user, to the workflow behind your offboarding process. Because PagerDuty has a remove action, it also qualifies for the Automatic offboarding method in Torii’s Offboarding settings, where the Start employee offboarding action removes a leaver from every app set up that way.

Offboarding starts from whichever HR system or identity provider you set as the source of truth (the system Torii trusts for who works at the company) for identity lifecycle automation. The User left trigger, which fires when that record marks someone as departed, governs how soon the PagerDuty removal runs: Torii checks workflow triggers every hour on the half-hour (Torii Help, Introduction to Workflows), and a User left trigger with Google or Okta as the source fires within an hour (Torii Help, Workflow Triggers).

When the person is moving to another job inside the company, Change PagerDuty user license downgrades the seat and keeps the account. Torii doesn’t do the on-call handover for you. Reassign schedules, escalation policies, and open incidents in PagerDuty first (steps 3 and 4 of the Users page method), so the delete can go through.

Use the PagerDuty REST API

The REST API follows the same order as the Users page, with the checks first and the delete last. Each call goes to api.pagerduty.com with an Authorization: Token token=<API_KEY> header and an Accept: application/vnd.pagerduty+json;version=2 header.

1. Create an API key with write access

Create a REST API key with the read-only restriction left off, since the delete call in step 5 writes to the account. A scoped OAuth app needs users.write, plus teams.write for step 4.

2. Look up the user ID

Call GET /users?query=<name> to find the person’s ID. The query matches names (PagerDuty doesn’t document email matching), and the response lists each match under users[] with its id, name, and email.

3. Check on-call shifts and open incidents

Call GET /oncalls?user_ids[]=<id> with since set to now and until up to 90 days out, since both default to the current time and PagerDuty caps on-call lookups at 90 days in the future. Then call GET /incidents with the same user filter, the triggered and acknowledged statuses, and date_range=all, so open incidents older than the default one-month window are included. Anything returned means the handover from the Users page method (steps 3 and 4) isn’t finished.

4. Remove the user from teams

Send DELETE /teams/{id}/users/{user_id} for each team the person belongs to.

5. Delete the user

DELETE https://api.pagerduty.com/users/{id} removes the account and returns 204 on success. PagerDuty’s Delete a user reference spells out the failure case: “Returns 400 if the user has assigned incidents unless your pricing plan has the offboarding feature and the account is configured appropriately.”

The same page adds a timing caveat for accounts that rely on reassignment: “Note that the incidents reassignment process is asynchronous and has no guarantee to complete before the api call return.” Teams that provision through SCIM can send DELETE https://api.pagerduty.com/scim/v2/Users/{id} instead.

# Needs curl and jq. Use a REST API key without the read-only restriction.
export PD_KEY="your-api-key"
H_AUTH="Authorization: Token token=$PD_KEY"
H_ACCEPT="Accept: application/vnd.pagerduty+json;version=2"

# 1. Find the user ID by name
curl -s -G "https://api.pagerduty.com/users" -H "$H_AUTH" -H "$H_ACCEPT" \
  --data-urlencode "query=Jane Doe" | jq '.users[] | {id, name, email}'

export PD_USER="PXXXXXX"

# 2. On-call shifts from now to 90 days out (want 0)
#    since/until default to now; -v+90d is BSD/macOS date, use -d "+90 days" on GNU
curl -s -G "https://api.pagerduty.com/oncalls" -H "$H_AUTH" -H "$H_ACCEPT" \
  --data-urlencode "user_ids[]=$PD_USER" \
  --data-urlencode "since=$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --data-urlencode "until=$(date -u -v+90d +%Y-%m-%dT%H:%M:%SZ)" | jq '.oncalls | length'

# 3. Open incidents of any age (want 0)
curl -s -G "https://api.pagerduty.com/incidents" -H "$H_AUTH" -H "$H_ACCEPT" \
  --data-urlencode "user_ids[]=$PD_USER" \
  --data-urlencode "date_range=all" \
  --data-urlencode "statuses[]=triggered" \
  --data-urlencode "statuses[]=acknowledged" | jq '.incidents | length'

# 4. Remove the user from a team (repeat per team ID)
curl -s -o /dev/null -w "%{http_code}\n" -X DELETE \
  "https://api.pagerduty.com/teams/PTEAMID/users/$PD_USER" -H "$H_AUTH" -H "$H_ACCEPT"

# 5. Delete the user: 204 means removed, 400 means assigned incidents remain
curl -s -o /dev/null -w "%{http_code}\n" -X DELETE \
  "https://api.pagerduty.com/users/$PD_USER" -H "$H_AUTH" -H "$H_ACCEPT"

Whichever method you pick, schedules, escalation policies, and open incidents change hands before the delete, and on SCIM accounts that handover also comes before the identity provider shutdown. A single departure on a small account needs nothing beyond the Users page. A team that offboards people every week can let Torii run Remove PagerDuty user off the HR or identity provider trigger alongside every other app, and keep the API for scripted bulk cleanup. For the separate, periodic question of who still holds PagerDuty access, compare these PagerDuty access review methods.