--- title: "PagerDuty Integration" description: "Automate on-call incident response. Create and run the full incident lifecycle, fire alerts and change events through the Events API v2, and administer services, escalation policies, schedules, users, teams, and maintenance windows." url: https://flowrunner.ai/integrations/pagerduty date_modified: 2026-09-04T14:00:23-07:00 --- # PagerDuty [Developer Tools](https://flowrunner.ai/integrations/category/developer-infrastructure) Automate on-call incident response. Create and run the full incident lifecycle, fire alerts and change events through the Events API v2, and administer services, escalation policies, schedules, users, teams, and maintenance windows. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 1 trigger · 69 actions · OAuth · available [PagerDuty website](https://pagerduty.com/) · [Platform Documentation](https://developer.pagerduty.com/api-reference/) · Capability data verified 2026-07-30 1. On New Triggered Incident fires when a service pages 2. Agent reads the incident title, urgency, and the alert payload that opened it 3. Agent correlates the incident against recent deploys and open maintenance windows 4. Agent posts the incident summary and a runbook link to the on-call channel 5. Agent pulls who is on call now and names the responder in the summary 6. The on-call engineer acknowledges the incident in PagerDuty before the agent runs any recovery step ## What This Integration Enables FlowRunner agents use PagerDuty to turn a raw signal into a well-formed incident and to keep on-call operations in sync with the rest of the stack. An agent can open an incident when a check fails, post a status update to subscribers, snooze or re-assign, request an extra responder, and record a change event so the incident correlates with the deploy that caused it. It can keep schedules, escalation policies, and team membership synchronized from other systems, and look up who is on call right now to route the page correctly. What it does not do is run the response on its own. The engineer who owns the page owns the decisions. ### Without FlowRunner **Noisy first minutes**: The responder opens several tools to figure out what paged and why **No correlation**: Nobody links the incident to the deploy that likely caused it **Manual context gathering**: On-call status, recent changes, and runbook links are collected by hand ### With FlowRunner **Context on arrival**: The agent posts urgency, likely cause, and the responder name with the page **Change correlation**: Recent deploys and change events are already attached to the incident **Human acknowledges first**: Recovery steps wait for the on-call engineer to acknowledge and decide ## Use Case Scenarios ### Well-formed incidents from monitoring signals A monitoring export lands with a set of failing checks. The agent reads each row and calls Trigger Alert into the Events API v2, reusing a deduplication key so a recovered check clears itself later with Resolve Alert. For the checks that represent a real outage, the agent calls Create Incident on the right service, attaches the failing check details, and correlates recent deploys with Send Change Event. The on-call engineer opens a fully described incident instead of a bare alert. ### Deploy-aware maintenance windows A deployment workflow is about to ship. Before it does, the agent calls Create Maintenance Window on the affected services to suppress the expected alert noise, records the deploy with Send Change Event, and removes the window when the deploy is confirmed healthy. Expected noise stays quiet. Real problems still page. ### Incident acknowledgement gate before recovery An incident triggers on a service that has an automated recovery step. The agent posts the incident and the proposed recovery action to the on-call channel, then waits. It does not run the recovery. Only after the on-call engineer acknowledges the incident in PagerDuty does the agent proceed, and it records the acknowledgement as part of the incident timeline. ## Human-in-Loop Highlight The human-in-loop moment here is the acknowledgement gate. When an incident triggers and a recovery action is on the table, the agent stops at exactly the point where judgment matters. It opens the incident, posts the context and the proposed action, and holds. The agent watches for the on-call engineer to acknowledge the incident in PagerDuty, using List Incident Log Entries to confirm the acknowledgement is real and to capture who did it. Only then does it run the recovery step. An unacknowledged page never triggers an automated action against production. The responder decides the response, and the timeline shows they did. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 69 actions ### Incidents 14 - **Create Incident** Open a new incident on a service, paging the on-call responders. Used to raise an alert from a flow when a check fails or a customer reports an outage. - **List Incidents** List incidents, filtered by status, service, or team. Used to build a live incident view or a digest. - **Get Incident** Retrieve a single incident's full detail. - **Update Incident** Change an incident's status, urgency, assignment, or priority. - **Merge Incidents** Merge duplicate incidents into one. Used to collapse a storm of related pages into a single response. - **Snooze Incident** Snooze an incident for a set period. - **Create Incident Note** Add a note to an incident's timeline. Used to record context or a hand-off decision where the next responder will see it. - **List Incident Notes** List the notes recorded on an incident's timeline. Used to read the running commentary before taking over a live incident. - **Create Status Update** Post a status update to an incident's subscribers. - **Create Responder Request** Request that an additional responder be paged into an active incident. Used to pull in extra help during a live incident. - **List Incident Alerts** List the underlying monitoring alerts grouped into an incident. Used to inspect what actually triggered the page. - **Get Incident Alert** Retrieve one alert within an incident, including its body and the service it came from. Used to drill into a specific signal. - **Update Alert** Resolve a single alert or move it to a different incident. Used to clear one signal independently of the incident, or to regroup a storm. - **List Incident Log Entries** List the log entries for an incident. Used to pull the incident's audit timeline and confirm an acknowledgement. ### Services 5 - **List Services** List the services in the account. - **Get Service** Retrieve a single service. - **Create Service** Create a service. Used to onboard a new system into on-call coverage. - **Update Service** Update a service's configuration. - **Delete Service** Delete a service. ### Escalation Policies 5 - **List Escalation Policies** List the escalation policies in the account. - **Get Escalation Policy** Retrieve a single escalation policy. - **Create Escalation Policy** Create an escalation policy. - **Update Escalation Policy** Update an escalation policy. - **Delete Escalation Policy** Delete an escalation policy. ### Schedules 9 - **List Schedules** List the on-call schedules. - **Get Schedule** Retrieve a single schedule. - **Create Schedule** Create an on-call schedule. - **Update Schedule** Update a schedule. - **Delete Schedule** Delete a schedule. - **List Schedule Overrides** List the overrides on a schedule within a date range. Used to see who is covering instead of the default rotation. - **Create Schedule Override** Put a specific user on call for a time window in place of the normal rotation. Used to arrange cover for a planned absence. - **List On-Calls** List who is on call now across schedules and escalation policies, filterable by user, schedule, or policy. Used to name the right responder during a live incident. - **List Schedule On-Calls** List the users on call for one named schedule, optionally within a time window. Used when the question is who covers this specific rotation rather than who is reachable right now. ### Users 7 - **List Users** List the users in the account. - **Get User** Retrieve a single user. - **Create User** Create a user. - **Update User** Update a user. - **Delete User** Delete a user. - **List User Contact Methods** List a user's contact methods, covering email, phone, SMS, and push. Used to confirm how a responder can actually be reached. - **List User Notification Rules** List how and when a user is notified for high and low urgency incidents. Used to audit a responder's alerting setup before relying on it. ### Teams 9 - **List Teams** List the teams in the account. - **Get Team** Retrieve a single team. - **Create Team** Create a team. - **Update Team** Update a team. - **Delete Team** Delete a team. - **Add User To Team** Add a user to a team, optionally with a team role of manager, responder, or observer. - **Remove User From Team** Remove a user from a team. Used when a member leaves a squad. - **Add Escalation Policy To Team** Associate an escalation policy with a team so the team owns it. - **Remove Escalation Policy From Team** Remove the association between an escalation policy and a team. ### On-Call 1 - **List Priorities** List the incident priority levels configured in the account. Used to set priority on a new incident. ### Maintenance Windows 5 - **List Maintenance Windows** List the maintenance windows. - **Get Maintenance Window** Retrieve a single maintenance window. - **Create Maintenance Window** Create a maintenance window to suppress expected alerts around a deploy. - **Update Maintenance Window** Update a maintenance window. - **Delete Maintenance Window** Delete a maintenance window. ### Tags 5 - **List Tags** List the tags in the account. - **Create Tag** Create a tag. - **Delete Tag** Delete a tag. - **List Tagged Entities** List the entities that carry a given tag. - **Change Entity Tags** Add or remove tags on an entity. ### Business Services 5 - **List Business Services** List the business services. - **Get Business Service** Retrieve a single business service. - **Create Business Service** Create a business service. - **Update Business Service** Update a business service. - **Delete Business Service** Delete a business service. ### Events 4 - **Trigger Alert** Fire an alert into the Events API v2 with a routing key and deduplication key. Used to open or update an alert from a monitoring signal. - **Acknowledge Alert** Acknowledge an Events API v2 alert by deduplication key. - **Resolve Alert** Resolve an Events API v2 alert by deduplication key, so recoveries clear automatically. - **Send Change Event** Record a change event, such as a deploy, in the Events API v2 so incidents correlate with changes. ## Triggers 1 triggers ### Event Triggers 1 - **On New Triggered Incident** Fires when a new incident is triggered in PagerDuty. Starts an incident-response workflow the moment a service pages, before a human has acknowledged, so the agent can gather context and post it to the on-call channel while the responder is still reading the page. ## Frequently Asked Questions ### What can FlowRunner do with PagerDuty? FlowRunner agents can run Create Incident, List Incidents, and Get Incident in PagerDuty, plus 66 more actions. ### Does connecting PagerDuty to FlowRunner require OAuth? Yes. PagerDuty connects to FlowRunner with OAuth 2.0, so agents authenticate without handling raw credentials. ### Can PagerDuty trigger a FlowRunner workflow automatically? Yes. PagerDuty supports 1 trigger that can start a FlowRunner workflow automatically. **Work at PagerDuty?** This integration exposes PagerDuty to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/pagerduty. Site index: https://flowrunner.ai/llms.txt