- Home
- Resources
- Integrations
- PagerDuty
Claude PagerDuty connectorWhat Claude can do in your PagerDuty account.
The Claude PagerDuty connector exposes 64 tools. 42 read incidents, alerts, schedules, services and status pages, and 22 can open incidents, add responders, edit rotations or delete settings. Here: what each one does, what you approve, and which documentation to trust.
Verified Trustpilot reviews · AI, automation & growth agency
What changes when Claude can reach your PagerDuty
During an incident, nobody wants to click through five screens to learn who is on call or what was already tried. You ask Claude, it reads incidents, notes, schedules and change events in PagerDuty while it answers, and it can take the next step for you once you approve.
Get up to speed in the middle of the night. list_incidents shows what is open, list_incident_notes what responders already tried, and get_past_incidents or get_related_incidents whether this has happened before or is hitting other teams too.
Act without leaving the conversation. manage_incidents changes status, priority or assignees, add_responders brings more responders in, add_note_to_incident logs what you did, and create_status_page_post publishes a status page post.
Handle the rota. list_oncalls answers who is on call right now, and create_schedule_override covers a sick colleague's shift in one sentence.
Now what the directory sheet does not say. Its 64 tool names come from PagerDuty's self-hosted server, which PagerDuty has since archived; its current hosted server documents grouped tools instead. We explain that below. Nothing runs on its own either: no tool fires when an alert comes in. For wiring PagerDuty events into other apps, look at the PagerDuty n8n integration or the PagerDuty Make integration.
The vocabulary in one minute
Five words you will meet while plugging PagerDuty into Claude.
- Connector
- The link you set up once between Claude and an account you already own, so Claude can work in that account while it answers you.
- Tool
- One named action a connector opens to Claude. It picks the ones it needs by itself, and the directory sheet lists them by name.
- Authorization
- The sign-in screen of the service itself, where you hand Claude the access it will use. Granted once per person, and you can take it back.
- Approval
- The confirmation Claude waits for before it goes through with something that changes your account, shown in the chat when it matters.
- MCP
- The shared standard connectors are built on. It is what lets an assistant like Claude talk to an outside service such as PagerDuty.
Connect PagerDuty to Claude in three steps
- 01
Find PagerDuty in Claude
In Claude, open Customize, then Connectors, and look for PagerDuty in the list. On a Team or Enterprise workspace, an Owner or Primary Owner has to switch the connector on first, before each member can sign in.
- 02
Start the connection
Click Connect on the PagerDuty row, then sign in to PagerDuty in the window PagerDuty opens itself. If the link ever breaks, use Disconnect and connect again from the same place.
- 03
Read the authorization screen
Read PagerDuty's authorization screen before you accept. It belongs to PagerDuty, not to Claude, and it sets what the access covers. You can take that access back later from your PagerDuty account.
The 64 Claude PagerDuty connector tools, by what they do
PagerDuty gives Claude 64 tools: 42 that read your account, 22 that change something in it.
Two groups: what Claude reads and what it can change. The read and write labels come from PagerDuty's own tool table for these exact names. Tool names stay as Claude shows them.
- 42 read
- 22 write
Tools index
- get_alert_from_incident
- get_alert_grouping_setting
- get_change_event
- get_escalation_policy
- get_event_orchestration
- get_event_orchestration_global
- get_event_orchestration_router
- get_event_orchestration_service
- get_incident
- get_incident_workflow
- get_log_entry
- get_outlier_incident
- get_past_incidents
- get_related_incidents
- get_schedule
- get_service
- get_status_page_post
- get_team
- get_user_data
- list_alert_grouping_settings
- list_alerts_from_incident
- list_change_events
- list_escalation_policies
- list_event_orchestrations
- list_incident_change_events
- list_incident_notes
- list_incident_workflows
- list_incidents
- list_log_entries
- list_oncalls
- list_schedule_users
- list_schedules
- list_service_change_events
- list_services
- list_status_page_impacts
- list_status_page_post_updates
- list_status_page_severities
- list_status_page_statuses
- list_status_pages
- list_team_members
- list_teams
- list_users
- add_note_to_incident
- add_responders
- add_team_member
- append_event_orchestration_router_rule
- create_alert_grouping_setting
- create_incident
- create_schedule
- create_schedule_override
- create_service
- create_status_page_post
- create_status_page_post_update
- create_team
- delete_alert_grouping_setting
- delete_team
- manage_incidents
- remove_team_member
- start_incident_workflow
- update_alert_grouping_setting
- update_event_orchestration_router
- update_schedule
- update_service
- update_team
What Claude reads (42)
42 toolsForty-two tools that look at incidents, alerts, schedules, services, orchestrations, status pages, teams and users.
get_alert_from_incident
Opens a single alert attached to an incident, the raw signal behind it.
get_alert_grouping_setting
Shows one alert grouping setting, the rule that decides which alerts land together in a single incident.
get_change_event
Retrieves one of the events PagerDuty logs when someone alters a service, such as a release, with its details.
get_escalation_policy
Returns a specific escalation policy, the chain of people PagerDuty pages when the first responder does not answer.
get_event_orchestration
Reads a specific event orchestration, the routing logic PagerDuty applies to incoming events.
get_event_orchestration_global
Brings back the global rules of an orchestration, the ones applied to every event before any routing.
get_event_orchestration_router
Displays the router configuration of an orchestration, the part that decides which service each event reaches.
get_event_orchestration_service
Fetches the orchestration rules attached to one service, applied once an event has been routed to it.
get_incident
Pulls one incident by its ID, with the details responders look at first.
get_incident_workflow
Shows the details of one incident workflow, a predefined sequence of steps PagerDuty can run during an incident.
get_log_entry
Retrieves a single entry from the log, the audit trail of what happened in the account.
get_outlier_incident
Provides PagerDuty's outlier analysis for an incident, telling you whether it looks unusual compared with past ones.
get_past_incidents
Finds past incidents similar to a given one, so you can reuse what worked last time.
get_related_incidents
Lists incidents related to a given one, which helps you see whether several teams face the same outage.
get_schedule
Opens a specific on-call schedule, so Claude can explain the rotation in plain words.
get_service
Returns the details of a specific service, the unit PagerDuty attaches alerts and incidents to, with its current configuration.
get_status_page_post
Reads a single post from a status page, the public or internal notice about an incident or maintenance.
get_team
Displays a specific PagerDuty team and its details, the group that owns services, schedules and escalation policies in your account.
get_user_data
Retrieves the information of the user who is connected, in other words you as PagerDuty sees you.
list_alert_grouping_settings
Lists every alert grouping setting in the account.
list_alerts_from_incident
Lists the alerts that belong to one incident, the individual signals grouped under it.
list_change_events
Lists the events PagerDuty records across all services when something is released or altered.
list_escalation_policies
Lists all escalation policies in the account.
list_event_orchestrations
Lists the event orchestrations set up in your account, each one a set of routing rules for incoming events.
list_incident_change_events
Returns the service events PagerDuty links to a given incident, such as releases just before it started.
list_incident_notes
Lists the notes written on an incident by responders.
list_incident_workflows
Lists the incident workflows available in your account, the ready-made response sequences your admins prepared for serious incidents.
list_incidents
Lists incidents with filters, the main way to ask what is happening right now or what happened last week.
list_log_entries
Lists log entries, PagerDuty's audit trail of actions in the account.
list_oncalls
Shows the current on-call assignments across the account.
list_schedule_users
Lists the users on a schedule for a given time range.
list_schedules
Lists all on-call schedules in your account, the rotations that decide who gets paged, day and night.
list_service_change_events
Returns the release and alteration events recorded for a specific service, a quick way to see what moved on it recently.
list_services
Lists all services in your PagerDuty account, each one being a unit that receives alerts and opens incidents.
list_status_page_impacts
Lists the impact options available on a status page, the labels you pick when describing how bad an incident is.
list_status_page_post_updates
Lists the follow-up messages posted under a status page post, in order.
list_status_page_severities
Lists the severity levels configured for a status page, the scale your notices use to say how serious an incident is.
list_status_page_statuses
Lists the status options a status page offers, such as the states an incident notice can be in.
list_status_pages
Lists all status pages in your account, public or internal, with the names your customers or colleagues see.
list_team_members
Lists the members of a team, the people PagerDuty groups under it for services and schedules.
list_teams
Lists all teams in your PagerDuty account, the groups that own services, schedules and escalation policies.
list_users
Lists all users in the account, the people who can be paged or who sign in to PagerDuty.
What Claude can change (22)
22 toolsTwenty-two tools that open, add, edit, publish or delete. No source describes a confirmation of their own: the general rule below applies.
add_note_to_incident
Approval: see the ruleAdds a note to an incident, the running log responders share.
add_responders
Approval: see the ruleAdds responders to an incident, bringing more people into the response.
add_team_member
Approval: see the ruleAdds a user to a team.
append_event_orchestration_router_rule
Approval: see the ruleAppends a new rule to an orchestration router, changing where some incoming events are sent.
create_alert_grouping_setting
Approval: see the ruleCreates a new alert grouping setting, a rule for bundling alerts into fewer incidents.
create_incident
Approval: see the ruleOpens a new incident in PagerDuty, on the service you name.
create_schedule
Approval: see the ruleSets up a new on-call schedule.
create_schedule_override
Approval: see the ruleAdds an override to a schedule, a temporary swap of who is on call.
create_service
Approval: see the ruleRegisters a new service in PagerDuty, the unit that will receive alerts.
create_status_page_post
Approval: see the rulePublishes a new post on a status page, the notice your customers or colleagues read.
create_status_page_post_update
Approval: see the ruleAdds a follow-up message to an existing status page post.
create_team
Approval: see the ruleAdds a brand-new team to PagerDuty.
delete_alert_grouping_setting
Approval: see the ruleDeletes an alert grouping setting.
delete_team
Approval: see the ruleDeletes a team from your account.
manage_incidents
Approval: see the ruleChanges an incident's status, priority or assignees, for instance to acknowledge, resolve or reassign it.
remove_team_member
Approval: see the ruleRemoves a user from a team.
start_incident_workflow
Approval: see the ruleTriggers an incident workflow, running its predefined steps on an incident.
update_alert_grouping_setting
Approval: see the ruleModifies an alert grouping setting.
update_event_orchestration_router
Approval: see the ruleEdits the router of an event orchestration, which decides where incoming events go.
update_schedule
Approval: see the ruleUpdates an existing on-call schedule.
update_service
Approval: see the ruleUpdates a service's configuration.
update_team
Approval: see the ruleUpdates a team's details.
What Claude asks you before it acts
By default, Claude stops and asks for your go-ahead before each action it takes on an account for you. The request shows up in the chat, at the moment it matters.
On Team and Enterprise workspaces, owners decide whether members may let some actions through without being asked every time. They can also limit what a connector may do across the whole organization, for example keep reading open and close writing. That setting applies to everyone and nobody overrides it from their own account. And Claude works with your rights and nothing more: it acts through the PagerDuty access you authorized. In an incident, approvals come fast; read what the action does before you say yes.
Which plans it is available on
Out of the 819 sheets in the official directory, not one shows availability by plan. The per-connector answer is published nowhere: it is a real hole in the catalogue.
The general rule is published, though. Remote connectors are open to all users on Claude, Cowork, Claude Desktop and mobile, and desktop extensions install on Claude Desktop. On Team and Enterprise, an Owner or Primary Owner switches the connector on for the organization before each member can connect. For the current state on your account, the connector's own sheet in the official directory is the place to check.
Where the Claude PagerDuty connector stops
A connector is not an automation. Claude calls these tools while it answers you: nothing starts when an alert fires, an incident escalates or a shift begins.
This page rests on PagerDuty's own documentation only: no Claude help article covers this connector. The tool list is an observed floor, not a promise, since an admin can open actions that no public sheet shows. The directory's partner badge is not a security audit either, and Anthropic says so on every sheet: it does not pick the tools a publisher exposes and does not vouch that they behave as announced. Connect what comes from a publisher you trust, here PagerDuty itself. For another connector where official sources disagree, read the Claude gmail connector page.
Which tool list describes the PagerDuty connector Claude uses?
- Connector sheet in Claude's directory ↗read 30 September 2026It lists 64 tools one by one, such as list_incidents, create_incident and manage_incidents, the same names as PagerDuty's archived repository.
- PagerDuty knowledge base, PagerDuty MCP Server ↗4 September 2026It describes grouped tools for the hosted server, one to browse and one to manage each area, and states that the self-hosted server is deprecated and its repository archived.
- PagerDuty's GitHub repository, Tools Overview (self-hosted server) ↗archivedOut of dateIt documents each of the 64 names with a read or write label, for the self-hosted server that PagerDuty now calls deprecated.
What this page followsThe directory sheet still carries the tool names of the self-hosted server, while PagerDuty's knowledge base of September 2026 describes grouped tools on the hosted server. This page takes each tool's read or write label from the archived table, the only source that covers these exact names. What counts for your account is the list the connector shows once connected.
Need help connecting PagerDuty to Claude?
A person reads every message.


