Skip to main content

PagerDuty integration

Triage incidents, sync on-call signal, and automate alert workflows on behalf of your clients' PagerDuty accounts.

What it does

The PagerDuty integration lets your workflows react to incidents the moment they change and act on them without anyone opening PagerDuty. Connect a PagerDuty account once, then page the right people from upstream alerts, acknowledge, resolve, reassign or snooze incidents, pull in extra responders, post stakeholder updates, find who is on call, cover a shift with a schedule override, and mark deploys on a service timeline.

Connect a PagerDuty account

  1. Register an OAuth app in the PagerDuty account under Integrations → App Registration, then add a TaskJuice OAuth client for it under Settings → Integrations → OAuth clients.
  2. In your workspace, open Apps, choose PagerDuty and click Connect account.
  3. Sign in to the PagerDuty account you want TaskJuice to act on and approve the requested scopes.

Grant the scopes your workflows need. Reading and changing incidents needs incidents.read and incidents.write. The pickers need services.read, users.read, schedules.read, teams.read, escalation_policies.read and priorities.read. Triggers need webhook_subscriptions.read and webhook_subscriptions.write. The actions and triggers that need anything more say so below.

Triggers

Add a PagerDuty trigger to a workflow and publish. That is the whole setup.

TaskJuice creates a PagerDuty webhook subscription (v3) in the connected account for you. It points the subscription at an address only your workspace receives on, subscribes it to exactly the event types your published workflows use, and stores the signing secret PagerDuty returns. You do not need to create a subscription in PagerDuty or copy a URL.

The subscription covers the whole account, so you receive events for every service. Filter on event.data.service.id in your workflow if you only care about some services.

Incident lifecycle

  • pagerduty/incident-triggered: an incident is created (incident.triggered).
  • pagerduty/incident-acknowledged: an incident is acknowledged (incident.acknowledged).
  • pagerduty/incident-unacknowledged: an acknowledgement times out and the incident triggers again (incident.unacknowledged).
  • pagerduty/incident-resolved: an incident is resolved (incident.resolved).
  • pagerduty/incident-reopened: a resolved incident is reopened (incident.reopened).
  • pagerduty/incident-escalated: an incident escalates to another user in the same escalation level (incident.escalated).
  • pagerduty/incident-reassigned: an incident is reassigned to another user (incident.reassigned).
  • pagerduty/incident-delegated: an incident is reassigned to another escalation policy (incident.delegated).
  • pagerduty/incident-priority-updated: an incident's priority changes (incident.priority_updated).
  • pagerduty/incident-type-changed: an incident moves to a different incident type (incident.incident_type.changed).
  • pagerduty/incident-service-updated: an incident moves to a different service (incident.service_updated).

Collaboration

  • pagerduty/incident-annotated: a note is added to an incident (incident.annotated).
  • pagerduty/incident-status-update-published: a status update is posted (incident.status_update_published).
  • pagerduty/incident-responder-added and pagerduty/incident-responder-replied: a responder is requested, and the responder answers (incident.responder.added, incident.responder.replied).
  • pagerduty/incident-role-assigned: an incident role such as Incident Commander is assigned or unassigned (incident.role.assigned).
  • pagerduty/incident-conference-bridge-updated: the incident's conference bridge number or URL changes (incident.conference_bridge.updated).
  • pagerduty/incident-custom-fields-updated: incident custom field values change (incident.custom_field_values.updated). event.data.changed_custom_fields holds the previous values.
  • pagerduty/incident-task-created, pagerduty/incident-task-updated and pagerduty/incident-task-completed: incident tasks change (incident.task.*).

Automation

  • pagerduty/incident-workflow-started and pagerduty/incident-workflow-completed: a PagerDuty incident workflow runs (incident.workflow.*). Needs the incident_workflows.read scope.
  • pagerduty/incident-action-invocation-created, pagerduty/incident-action-invocation-updated and pagerduty/incident-action-invocation-terminated: an automation action runs on an incident (incident.action_invocation.*).

Services

  • pagerduty/service-created, pagerduty/service-updated and pagerduty/service-deleted: a service is added, changed or removed (service.*).
  • pagerduty/service-custom-fields-updated: service custom field values change (service.custom_field_values.updated).

TaskJuice verifies every delivery before it reaches your workflow. It recomputes an HMAC-SHA256 over the raw request body with the subscription's signing secret, then compares the hex digest with the v1= value in the X-PagerDuty-Signature header. During a secret rotation the header can carry several v1= values, and any one of them matching is enough.

What happens when you unpublish or disconnect

Unpublishing every PagerDuty trigger leaves the subscription registered for up to 90 days, so republishing needs no new setup. Deliveries in that window are discarded on arrival. Disconnecting the PagerDuty connection queues the subscription for deletion from the account right away.

Actions

Incidents

  • pagerduty/create-incident: open an incident on a service with a title, urgency and details.
  • pagerduty/get-incident: look up an incident by ID.
  • pagerduty/list-incidents: list incidents filtered by status, service, urgency or time range.
  • pagerduty/update-incident: change an incident's status, title or urgency.
  • pagerduty/acknowledge-incident: acknowledge an incident so responders stop being paged.
  • pagerduty/resolve-incident: resolve an incident, with an optional resolution note.
  • pagerduty/reassign-incident: reassign an incident to a user.
  • pagerduty/set-incident-priority: set an incident's priority. Needs priorities turned on in the account.
  • pagerduty/snooze-incident: snooze an acknowledged incident for up to 7 days.
  • pagerduty/merge-incidents: merge incidents into a target incident. This cannot be undone.
  • pagerduty/add-responder: ask another user to join an incident.
  • pagerduty/create-incident-note and pagerduty/list-incident-notes: add a note to an incident timeline, or read its notes.
  • pagerduty/create-status-update: post a status update. PagerDuty emails it to the incident's stakeholder subscribers.
  • pagerduty/list-incident-alerts: list the alerts grouped into an incident, including their custom details.
  • pagerduty/list-log-entries and pagerduty/get-log-entry: read incident timeline events.
  • pagerduty/start-incident-workflow: run a PagerDuty incident workflow on an incident. Needs the incident_workflows:instances.write scope and a PagerDuty plan that includes incident workflows.

Events API

  • pagerduty/send-event: trigger, acknowledge or resolve an alert through an Events API v2 integration, keyed by a deduplication key.
  • pagerduty/send-change-event: record a deploy or configuration change on a service. Change events show up next to incidents and never page anyone.

Both Events API actions authenticate with the service's 32-character Integration Key (the service's Integrations → Events API v2 tab), not with the connection.

On-call, people and services

  • pagerduty/find-on-call: list who is on call for a schedule, escalation policy or user over a time window.
  • pagerduty/list-schedules: list on-call schedules, optionally by name.
  • pagerduty/create-schedule-override: put a user on call for a time window, for example to cover a shift. Needs the schedules.write scope.
  • pagerduty/find-users and pagerduty/get-user: find users by name or email, or look one up by ID.
  • pagerduty/list-services and pagerduty/get-service: list services, or read one with its status and escalation policy.
  • pagerduty/create-maintenance-window: open a maintenance window on a service so planned work does not create incidents. Needs the services.write scope.

Known limitations

  • Several write actions take a From user. PagerDuty records the change against that user. When the connection belongs to a single PagerDuty user, you can leave it empty on the new actions.
  • Registering the webhook subscription needs a PagerDuty user who is allowed to manage the account's webhooks. If PagerDuty refuses it, reconnect with an account admin and republish.
  • Rate limits follow PagerDuty's per-token limits. TaskJuice retries 429 responses.
  • List actions page with offset and limit, up to 100 results per page. more: false in the response means there are no more pages.
Was this helpful?