Connect PagerDuty
PagerDuty is the on-call and paging layer that sits beside your PSA. Monitoring tools raise events, PagerDuty decides who is on call, pages that person through every channel they own, and tracks the…
Written By Christopher Scaminaci
Last updated 6 days ago
PagerDuty is the on-call and paging layer that sits beside your PSA. Monitoring tools raise events, PagerDuty decides who is on call, pages that person through every channel they own, and tracks the incident through to resolution. Around that core sit services, escalation policies, on-call schedules, teams, users and maintenance windows.
Connecting PagerDuty to StackJack gives your AI assistant a family of pd_ MCP tools — MCP (Model Context Protocol) tools are the standardized commands an AI assistant can call through StackJack. With them, your AI can:
- Answer the two questions you actually ask — who is on call right now, and what is currently paging
- Work an incident — read it, read its alerts, notes, timeline and related incidents, then acknowledge, resolve, reassign, re-prioritize, add a note, snooze it, request another responder, or merge duplicates
- Keep stakeholders informed — post a status update, and manage who is subscribed to receive them
- Manage the rota — read and edit schedules, rotations, overrides and custom shifts, and read or edit escalation policies
- Run onboarding and offboarding — users, their contact methods, their notification rules and their team memberships
- Silence planned work — open, move and end maintenance windows on the services you are working on
- Configure services — services, their integrations, their event rules and their feature settings
- Answer compliance questions — per-object audit trails for services, teams, users, schedules and escalation policies
StackJack now covers PagerDuty's whole published API rather than the incident-and-on-call core, so your AI can also:
- Change how alerts are routed — read and edit Event Orchestrations and their rules, the router and the unrouted path, cache variables, and the integrations that events arrive on. The older rulesets PagerDuty has since replaced are there too, so an account that still uses them is not stranded
- Run your status page — read and publish posts and post updates, manage the services, severities and impact levels they reference, and see who is subscribed. These reach your own customers, so every one of them is a change that needs approval
- Report on the numbers — incident and response analytics by service, team, escalation policy, responder or major incident, over any window you choose, as raw rows or as aggregates
- Run automation — list the scripts and jobs registered in PagerDuty, see what they are attached to, and invoke one. Invoking one runs a script on a machine you host, so it needs approval
- Shape incidents themselves — incident types, the custom fields on them, and incident workflows with their triggers, steps and the connections they use to reach other systems
- Describe your business services — what depends on what, which ones a status page shows, the custom fields on them, and how alerts are grouped on a service
- Wire up integrations — webhook subscriptions and what they deliver, extensions, add-ons and change events from your deployment pipeline
- Enrich events as they arrive — enrichment schemas, rules and the ServiceNow CMDB tables behind them, including bulk-loading records from a CSV file
- Provision users from your identity provider — the standard SCIM user interface, so joiners and leavers can flow in from the directory you already run. PagerDuty’s SCIM surface is users only — it publishes no group endpoint — so team membership is managed with the user and team tools above, not by a group sync
- Keep the account tidy — tags, status-update templates, account standards and their scores, vendor definitions, licences, the account audit trail, sign-in session policy and the list of addresses allowed to use the API
- Send an event in — raise, acknowledge or resolve an alert, or record a deployment, by sending an event straight to PagerDuty. See "Sending events in" below: this one needs a second key
How StackJack authenticates to PagerDuty
You give StackJack three things: an API key, your service region, and the email address of a PagerDuty user to act as. There is no client ID, no sign-in, and nothing to renew on a schedule.
The API key
Create it in PagerDuty under Integrations → Developer Tools → API Access Keys. Only an Admin or Account Owner can. PagerDuty shows the key once, so copy it while it is on screen.
When you create it, PagerDuty offers a Read-only tick box, and it is worth a moment's thought:
- Leave it ticked and PagerDuty itself refuses every change, no matter what StackJack asks for. Your AI can look at everything and alter nothing. This is a genuine safety posture that costs nothing, and it runs every read tool on the Free tier bar one — see below.
- Clear it if you want an AI to be able to acknowledge, resolve, schedule, and page.
A personal key created under My Profile → User Settings → API Access also works, but it can only reach what that person can reach, and it stops working the day they leave the account. For an integration, an account-level key is the better choice.
One read is the exception. "Get the current user" asks PagerDuty who the key belongs to, and PagerDuty answers that only for a personal key or an OAuth token — an account-level key has no single owner to report, so the call fails whichever way the Read-only box is set. Nothing else depends on it: ask for the user list, or for a user by id, instead. The tool says so in its own description.
The key never expires on its own. Rotate it when you decide to, and delete the old one in PagerDuty.
Your service region
PagerDuty runs the United States and Europe as separate services — separate systems, separate data, and separate keys. Choose the one that matches where you sign in:
- United States if your address is
app.pagerduty.com - Europe if your address is
app.eu.pagerduty.com
A key issued in one region is not valid in the other, and using the wrong one fails in a way that looks exactly like a bad key. StackJack stores this as your choice rather than as a web address, so the connection cannot drift onto the wrong region later.
Sending events in
Everything above travels on the API key. Sending an event is the exception. PagerDuty accepts incoming events on a separate service with its own credential — an Events API integration key, which you create on a single PagerDuty service, on that service's Integrations tab.
StackJack does not store it. You give it to your AI at the moment you ask for an event to be sent, and which key you give decides which service the event lands on. That is deliberate: a key here is scoped to one service, so there is nothing sensible to store once for the whole account.
Treat it the way you treat the API key. Anyone holding one can open an incident on that service and page whoever is on call for it, from anywhere on the internet.
The acting user email
PagerDuty requires a real user's email address on every change so it can record who made it, and it shows that person in the incident timeline. Several changes are refused outright without it.
Give the address of a PagerDuty user on this account — often a shared operations mailbox, or the person who owns the integration. It is not a login and it is not a secret. StackJack sends it only on changes and never on a read.
StackJack asks for it again whenever you edit the connector, alongside the key. That is deliberate: it is stored with the key, and asking for both is what stops an edit quietly blanking one of them.
Steps
- Sign in to PagerDuty as an Admin or Account Owner.
- Open Integrations, then Developer Tools, then API Access Keys, and create a key. Give it a description that identifies StackJack, so it is obvious what to revoke later.
- Decide whether to leave Read-only ticked. See above.
- Copy the key while it is on screen.
- Open Connectors in StackJack, choose PagerDuty, paste the key, pick your region, and enter an acting user email.
- Run a Test Connection. StackJack reads your account's feature list, which needs nothing more than a valid key pointed at the right region — so a failure means the key, the region, or both.
What to know before you let an AI loose on it
Some tools page real people. Creating an incident does not just write a record: it fires your escalation policy and notifies whoever is on call, potentially in the middle of the night. Requesting an additional responder does the same to one more person. Adding a note notifies the responders already on the incident. Posting a status update emails everyone subscribed to it, who are usually your own customer's stakeholders. These are labeled as changes that need approval.
What "needs approval" actually gets you. Two different things, and it is worth knowing which one you are relying on:
- Working with an AI assistant yourself. StackJack labels these tools as consequential, and assistants that honor that label — most do — show you what is about to happen and wait for you to confirm. The confirmation belongs to the assistant, not to StackJack, so an assistant that ignores the label will not stop.
- An automation running unattended. A StackJack automation cannot run any of these tools at all until someone signs off, in StackJack, that it may take consequential actions on its own. That sign-off is once, not per action: after it, the automation acts without asking again. Until it, the tool is refused.
If you want a hard stop rather than a prompt, the reliable control is the key itself — a Read-only key, or leaving those tools switched off for that connection.
Other tools silence alerting rather than delete data. Snoozing an incident stops it paging anyone for the duration. Deleting a service, or the event rules on one, stops events reaching it at all. Editing who is on call can leave nobody on call. Each of these is treated as a change that needs approval, because the failure mode is a monitoring blind spot: a real incident stops reaching anyone.
Opening a maintenance window is deliberately NOT treated that way. It suppresses paging for the services you name, which is exactly what it is for, and it has a stated end time. It is not labeled as a change that needs approval, so nothing pauses before it runs. If you would rather it were, say so and it can be changed.
An edit that replaces the whole object now asks first. PagerDuty edits some records by taking the whole object back, so anything you leave out is gone: a partial edit removes what it omits, and a schedule with nobody on it pages nobody. Seventeen tools work that way. Twelve replace the whole record — editing a service, a schedule (current or legacy), an escalation policy, a status-update template, a standard, a business service, an add-on, a change event, an Event Enrichment, or either kind of Event Orchestration cache variable. Five replace a LIST inside the record, which is the same loss in a smaller place: editing a maintenance window replaces the services and teams it covers, so a service you leave out starts paging again the moment you save; editing a service integration replaces its email parsers and filters; editing a custom shift replaces its assignments, so an assignee you leave out is off the shift; and editing a schedule override or a rotation event replaces the member and the window, or the recurrence, it was built with. All seventeen are labeled as changes that need approval, and each says in its own description what an omission costs. For the Event Enrichment and the Event Orchestration, the field that goes missing most easily is the owning team, and losing it takes the team's access with it. Ask your AI to read the current definition first and send it back complete.
Every other edit is a partial update that changes only the fields you send, and those are not labeled that way.
Creating a user sends an invitation and consumes a paid PagerDuty license. It is treated as a change that needs approval for that reason as much as any other.
Creating a service integration hands out a key. The reply carries an integration key that can trigger incidents on that service from anywhere on the internet. Treat it the way you would treat any credential. The same is true of an Event Orchestration and of a ruleset: reading either one back shows you the live keys routed to it.
Some areas need PagerDuty to switch them on for your account. Event enrichment and the API address allow-list are early-access features PagerDuty grants per account — ask your PagerDuty account team if you want them. Status pages, alert grouping and automation actions depend on your PagerDuty plan. Where a feature is not enabled for you, PagerDuty refuses the call rather than answering with nothing, so your AI will tell you it was refused rather than quietly report that there is nothing there.
A few tools are for accounts still using the older way of doing something. PagerDuty has replaced rulesets with Event Orchestrations, and incident custom fields now live on incident types. Both older sets are still here so an account that has not moved yet keeps working, and each tool says in its own description that it is the superseded one and what replaced it.
What comes back
PagerDuty answers with its own JSON and StackJack passes it through unchanged. A single record comes back under a name that matches it — an incident under incident, a service under service — and a list comes back under the plural, alongside the page size, the offset, and a flag saying whether there is more.
Long reads stop at ten thousand records
PagerDuty refuses a request that reaches past record 10,000. It answers with an error rather than an empty page, so there is no way to page through a busy account from end to end in one sweep. Narrow by date, team or service instead. The tools say so in their own descriptions, and an assistant that follows them will filter rather than page on.
You will also notice that the record count on a response is usually empty. PagerDuty leaves it out unless it is asked for, because working it out is slow, so StackJack does not ask. Read the "more" flag instead of the count.
Plans and limits
Read tools are available on the Free tier. Every change needs Pro — creating a service, editing a schedule, adding a team member, opening a maintenance window, and equally the ones that page a human, silence alerting, cannot be undone, hand out a key or spend money. That last group is labeled as changes that need approval — see above for what that label does and does not stop. Business offers the same tool set as Pro with a higher monthly call quota.
See the generated PagerDuty tool reference for the current inventory, plan assignment, input schemas, and destructive-action labels.
PagerDuty allows 960 requests a minute and counts them against the key, not against StackJack — so anything else using the same key spends the same allowance. Give StackJack its own key rather than sharing one. StackJack paces requests below that and backs off on its own when PagerDuty says to, which usually makes a large report slower rather than failed. Pacing smooths a burst; it does not guarantee every call arrives. Narrow the read, honor any retry delay, and check whether a change landed before repeating it — see Retrying a failed or timed-out write.
Several customers
One key reaches one PagerDuty account, and PagerDuty has no parent-and-child construct — so an MSP holding keys for several customers holds one per customer. Add one connection per account from the connector's card, name it after the customer, and your AI names it on each call. Omit the name and the call runs against your default connection. Pin an endpoint to one connection when an AI should never reach past a single customer. See Several connections of one connector.
Inside a single account, Teams is the only grouping PagerDuty enforces, and most reads accept a team filter.
Troubleshooting
"PagerDuty rejected the API key" — check the region first. A key issued in Europe sent to the United States service fails exactly like a bad key, and the other way round. If the region is right, the key has been disabled or deleted in PagerDuty; create a new one and paste it in.
Reads work but every change is refused — the key is marked Read-only, and PagerDuty is enforcing that on its side. Create a replacement without Read-only ticked. If it is a personal key rather than an account key, the other cause is the permissions of the person who created it.
A change is refused and mentions a missing user — the acting user email is missing or is not a user on this account. Re-open the connector and enter an address that belongs to a real PagerDuty user.
A record is "not found" that you can see in PagerDuty — check the region. The other region's account genuinely does not hold it, and that is what a not-found answer means here.
A wide read stops with an error about a limit — you have reached the ten-thousand-record ceiling. Add a date range, or filter by team, service or status. There is no page size to raise.
Everything slows down or comes back throttled — something else is using the same API key. Give StackJack its own.
PagerDuty tools
pd_ · 478 tools · Free 233 · Pro 245
Account
Audit
Licenses
Notifications
OAuth Delegations
Paused Incident Reports
Session Configurations
SRE Agent
Standards
Tags
Templates
Vendors
Analytics
Automation Actions
Enrichment Integrations
Enrichment Schemas
Event Enrichments
Escalation Policies
Event Orchestrations
Recommendations
Rulesets
Events API
Incident Custom Fields
Incident Types
Incident Workflows
Workflow Integrations
Incidents
Add-ons
Change Events
Extension Schemas
Extensions
Webhooks
IP Allow Lists
Log Entries
Maintenance Windows
On-Call
Schedules
Schedules (legacy v2)
SCIM Provisioning
Alert Grouping Settings
Business Services
Service Custom Fields
Service Dependencies
Services
Status Dashboards
Status Pages
Teams
Users
More in Connector guides
Connect Acronis Cyber Protect CloudConnect Action1Connect AddigyConnect AlertOpsStill need help? Ask the team