Reference · built on requestConnectorMessaging & notifications

PagerDuty

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

Request accessPricing ↗

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.

Inputs

  • 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

Requirements

  • 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