Reference · built on requestConnectorMessaging & notifications

PagerDuty

Incidents, services, escalation policies, and on-call schedules from PagerDuty, with alert events and incident updates.

Request PagerDutyAsk about this listing

About

PagerDuty is an incident management service. Its REST API v2 at api.pagerduty.com exposes incidents, services, escalation policies, schedules, on-calls, users, teams, and webhook subscriptions as JSON resources. The Events API v2 at events.pagerduty.com/v2/enqueue takes machine alerts and change events from monitoring tools and routes them to a service. V3 webhooks push incident events such as incident.triggered and incident.resolved to a URL you choose.

Through Fibric, an operator watches who is on call and which incidents are open, then proposes an acknowledgement, a note, a status update, or a new alert event. You approve. The change is applied once and leaves a receipt.

This is a reference listing. It documents what Fibric would read from PagerDuty and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

What it reads

  • Incidents with their alerts, notes, and log entries through GET /incidents, /incidents/{id}/alerts, /incidents/{id}/notes, and /incidents/{id}/log_entries
  • Services, escalation policies, teams, and users through GET /services, /escalation_policies, /teams, and /users
  • Who is on call for a time range through GET /oncalls, and schedule membership through GET /schedules/{id}/users
  • Incident events pushed by v3 webhook subscriptions: incident.triggered, incident.acknowledged, incident.escalated, incident.resolved, incident.reopened, and incident.priority_updated
  • Change events per service through GET /change_events and GET /services/{id}/change_events
  • Incident metrics and raw incident records through the Analytics endpoints under /analytics/metrics and /analytics/raw

Proposed actions

  • Target capability: propose acknowledging, resolving, escalating, or reassigning an incident through PUT /incidents/{id}, or up to 250 at once through PUT /incidents
  • Target capability: propose a note on an incident through POST /incidents/{id}/notes
  • Target capability: propose a status update to incident subscribers through POST /incidents/{id}/status_updates
  • Target capability: propose a trigger, acknowledge, or resolve alert event with a dedup_key through the Events API v2 at events.pagerduty.com/v2/enqueue
  • Target capability: propose a schedule override for a named user and time range through POST /schedules/{id}/overrides

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Answer an outage with the right people

    When incident.triggered arrives, the operator reads the on-call for the service's escalation policy and proposes a note and a status update. You approve; both are posted once.

    With Uptime Response

  • Hand off on-call without dropping incidents

    Before a shift boundary, the operator lists open incidents per escalation policy alongside GET /oncalls and proposes reassignments and a schedule override wherever coverage has a gap.

    With On-call Handoff

  • Tell support what engineering knows

    An acknowledged or resolved incident from the webhook feed becomes a proposed customer-facing notice for the support queue, with the incident number and time attached.

    With Outage Notice

  • Quiet the alerts nobody acts on

    Alerts that resolve with no acknowledgement are counted per service over a period. The operator proposes which sources should send change events instead of alert events.

    With Alert Noise

What it needs

  • A PagerDuty account; only account administrators can generate account API tokens
  • An account with Advanced Permissions if user API tokens are used instead of an account token
  • An Events API v2 integration on each service that will receive alert events, which supplies the routing_key
  • A publicly reachable HTTPS URL for v3 webhook subscriptions that returns 2xx within 5 seconds
  • A From header carrying a valid user's email when incidents are created through REST API v2
Authentication
A PagerDuty account API token or user API token sent as Authorization: Token token=..., or an OAuth 2.0 app token with scopes such as incidents.write; Events API calls carry a 32-character integration key as routing_key.

Limits

  • REST rate limit of 960 requests per minute per account API key, user, or app; 429 with ratelimit-reset headers when exceeded
  • Events API v2 accepts about 120 calls per minute per integration key and payloads up to 512 KB
  • Classic pagination stops at 10,000 records per query; narrow with filters to read more
  • Webhooks retry for up to 48 hours, and three consecutive dropped deliveries disable the subscription for 24 hours

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request PagerDuty

Questions and answers

Which PagerDuty webhook version does this listing use?
V3. You create a webhook subscription through REST API v2 with the event types you want and a filter of type service_reference, team_reference, or account_reference. Each delivery carries one event and an X-PagerDuty-Signature header, an HMAC SHA-256 of the body under the subscription secret.
Do alert events and incident updates use the same API?
No. Alert events go to the asynchronous Events API v2 with a routing_key and return 202. Incident acknowledgements, notes, and status updates go to the synchronous REST API v2 at api.pagerduty.com, which needs an API token and a From header for incident creation.
How are duplicate alerts avoided?
Every alert event has a dedup_key of up to 255 characters. Later trigger, acknowledge, or resolve events with the same key and routing_key apply to the open alert. After the alert resolves, a new trigger with that key opens a new alert.
Ask about PagerDuty

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with PagerDuty through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy