PagerDuty - Rootly

For a more seamless and deeper on-call experience, consider using Rootly On-Call. See how Rootly On-Call compares to PagerDuty.

The PagerDuty integration connects Rootly with PagerDuty so teams can coordinate incidents, alerts, and on-call response across both platforms. This integration is a strong fit for teams that already use PagerDuty for alerting or on-call management and want Rootly to act as the central place for incident coordination, workflows, and response automation. With the PagerDuty integration, you can:

Import, link, and sync services from PagerDuty into Rootly
View on-call personnel directly from Slack
Page PagerDuty services, escalation policies, and users from Rootly
Invite on-call responders into incidents and assign incident roles automatically
Keep key incident and alert activity aligned between Rootly and PagerDuty
Ingest supported PagerDuty webhook events as Rootly alerts

Before You Begin

Before setting up the PagerDuty integration, make sure you have:

A Rootly account with permission to manage integrations
A PagerDuty account with access to authorize integrations
The services, escalation policies, or users you want Rootly to page
Slack connected as well, if you want to use Slack-based on-call and paging flows

PagerDuty Permissions

PagerDuty permissions in Rootly are tied to the PagerDuty user who completes the OAuth connection. That means Rootly can only read from and write to the PagerDuty objects that the authenticated PagerDuty user has access to. Choose the PagerDuty account carefully, and use a service account when possible so the integration remains stable over time.

Installation

Open PagerDuty in the integrations catalog

Locate PagerDuty in the Integrations catalog and select Setup.

PagerDuty in the Rootly integrations catalog

During setup, you will be prompted to sign in to PagerDuty or create a PagerDuty account if needed.

Authorize Rootly in PagerDuty

After signing in, grant Rootly permission to connect to your PagerDuty account.

Complete the installation

Once authorization is complete, the PagerDuty integration is connected in Rootly.

Set Up PagerDuty Webhooks

PagerDuty webhooks allow Rootly to receive supported PagerDuty webhook events for alerts and incident-related activity.

Rootly attempts to create the webhook for you automatically if the authenticated PagerDuty user has permission to create webhooks. If not, you can still create the webhook manually in PagerDuty.

Via the PagerDuty Web UI

Open Generic Webhooks in PagerDuty

In PagerDuty, navigate to Integrations > Generic Webhooks.

Create a new webhook

Select + New Webhook to open the webhook creation form.

Enter the Rootly webhook settings

Use the following configuration in PagerDuty:

Webhook URL: https://webhooks.rootly.com/webhooks/incoming/pagerduty_webhooks
Scope Type: Choose one of:
- Service — only events for the selected service are sent to Rootly
- Team — only events for the selected team are sent to Rootly
- Account — events across the PagerDuty account are sent to Rootly
Description: Optional
Custom Header Name: secret
Custom Header Value: <secret>

You can find the webhook URL and header secret in Rootly on the Integrations > PagerDuty setup screen.

PagerDuty webhook URL and secret in Rootly

The webhook URL is shared across Rootly accounts. The secret value is unique to your Rootly account.

Choose webhook event subscriptions

Rootly supports the following PagerDuty webhook event types:

incident.acknowledged
incident.annotated
incident.delegated
incident.escalated
incident.priority_updated
incident.reassigned
incident.reopened
incident.resolved
incident.responder.added
incident.responder.replied
incident.triggered
incident.unacknowledged
pagey.ping

Rootly recommends selecting the supported incident events relevant to your Rootly workflows.

Finish the webhook setup

After completing the form, select Add Webhook.PagerDuty may display a PagerDuty-generated webhook secret as part of its confirmation flow. You do not need that value for the Rootly integration.

Via the PagerDuty API

PagerDuty webhooks can also be created through the PagerDuty API. Use the same Rootly endpoint and secret shown in the web UI setup:

URL: https://webhooks.rootly.com/webhooks/incoming/pagerduty_webhooks
Header: secret: <TOKEN>

You can find the secret token on the Rootly Integrations > PagerDuty setup screen. Use the same supported event list shown above when configuring subscriptions.

Smart Defaults

Smart Defaults help teams get started with the PagerDuty integration faster by preconfiguring common behaviors that would otherwise require manual workflow setup. This is useful for teams that want a simpler PagerDuty setup in Rootly without having to build every automation from scratch on day one. Smart Defaults cover two directions of activity:

Rootly to PagerDuty for paging, inviting responders, and resolving linked PagerDuty incidents
PagerDuty to Rootly for alert ingestion, Slack notifications, incident creation, and sync-related behaviors

To review or update these settings, go to Integrations > PagerDuty > Configure.

Rootly to PagerDuty

The first section of Smart Defaults controls actions that begin in Rootly and trigger behavior in PagerDuty.

Open the Rootly to PagerDuty settings

In the PagerDuty configuration screen, locate the Rootly to PagerDuty section.

Configure automatic paging on incident creation

The Auto-page on-call responder when an incident is created setting allows Rootly to notify PagerDuty responders as soon as a Rootly incident is created.Rootly determines who to page based on the selected PagerDuty service or escalation policy.If both are configured, the selected escalation policy overrides the escalation policy linked to the selected service.The services and escalation policies shown in these dropdowns are imported from your connected PagerDuty workspace.

Configure automatic Slack invitations for on-call responders

The Auto-invite on-call responder to new incident Slack channel setting allows Rootly to invite PagerDuty on-call responders into the new incident Slack channel when the incident is created.Rootly determines who to invite using the selected PagerDuty service or escalation policy. If both are configured, the escalation policy overrides the one linked to the selected service.This setting requires Slack to be connected in Rootly.

Configure automatic resolution of linked PagerDuty incidents

The Auto-resolve PagerDuty incident setting allows Rootly to resolve the linked PagerDuty incident when the Rootly incident is resolved.This is a one-way action from Rootly to PagerDuty. If you want PagerDuty activity to create or update alerts in Rootly, see Alert Ingestion below.

PagerDuty to Rootly

The second section of Smart Defaults controls actions that begin in PagerDuty and affect Rootly.

Open the PagerDuty to Rootly settings

In the PagerDuty configuration screen, locate the PagerDuty to Rootly section.

Send supported PagerDuty alerts to Rootly

The Send PagerDuty alerts to Rootly setting allows Rootly to ingest supported PagerDuty webhook events as alerts.This depends on the PagerDuty webhook being configured correctly. To complete setup, follow the instructions on the Installation page.This setting applies to supported PagerDuty webhook event types, not every possible PagerDuty event.

Notify a Slack channel when PagerDuty alerts arrive

The Notify Slack channel of new PagerDuty alerts setting allows Rootly to send PagerDuty alert messages into a selected Slack channel.Enable Send PagerDuty alerts to Rootly first, then choose the Slack channel you want Rootly to notify.You can use Send Test to verify that the Slack channel is configured correctly.Rootly refreshes Slack channels on a daily basis. If your channel does not appear in the dropdown, use Refresh channels to load the latest channels.If the selected channel is private, make sure the Rootly Slack bot has been added to that channel first.

Automatically create incidents from PagerDuty alerts

The Automatically create incidents in Rootly from PagerDuty alerts setting allows Rootly to create incidents automatically from incoming PagerDuty alerts.This setting is useful for teams that want PagerDuty events to drive incident creation in Rootly, but it should be enabled intentionally since not every alert should necessarily become a Rootly incident.

Additional PagerDuty Settings

Depending on your configuration, the PagerDuty integration can also include additional settings for:

Default PagerDuty incident title and description values
Service and team sync or import behavior
Other PagerDuty-to-Rootly coordination options

Use these alongside Smart Defaults when you want a broader PagerDuty configuration beyond the most common automation patterns.

Smart Defaults Notes

Smart Defaults simplify common PagerDuty use cases, but they do not replace every possible custom workflow
Some Smart Default settings depend on Slack being connected in Rootly
PagerDuty services and escalation policies used in these settings are imported from your PagerDuty workspace
Automatically creating incidents from PagerDuty alerts should be reviewed carefully before enabling in production

Import Teams

You can import PagerDuty teams into Rootly teams from the Teams page. This is useful when you want to align your Rootly team structure with your existing PagerDuty configuration. Once imported, Rootly can use the team relationship during incident workflows, escalation actions, and on-call lookups.

Workflow Actions

The following workflow actions are available for the PagerDuty integration.

Page PagerDuty On-Call

Use this action to page an on-call responder through PagerDuty. In practice, this creates or updates a PagerDuty incident from the Rootly incident.

In PagerDuty, paging is tied to incident creation and responder assignment.Each Rootly incident can only be linked to one PagerDuty incident.

Choose the PagerDuty service or responder target

The Service field specifies which PagerDuty service should be paged.If you have imported PagerDuty services into Rootly, you may be able to reference them dynamically from the workflow configuration.PagerDuty requires every incident to be associated with a service.

Optionally target an escalation policy or specific users

The Escalation Policy field lets you override the default escalation policy associated with the selected service.The Users field lets you page specific PagerDuty users instead of relying on the default service routing.

Set the PagerDuty incident details

Use these fields to control how the PagerDuty incident is created:

Title
Urgency
Message

The Message field supports Liquid syntax.

Use the Incident Variable Explorer to test Liquid values before adding them to your workflow action.

Choose whether to reuse or create a new PagerDuty incident

The Always Create New PagerDuty Incident on Page setting controls what happens if the Rootly incident is already linked to a PagerDuty incident.If enabled, Rootly creates a new PagerDuty incident, but that new incident is not linked back to the Rootly incident.If disabled, Rootly continues using the existing linked PagerDuty incident and may add responders to that incident instead.

Adding responders to an existing PagerDuty incident may depend on PagerDuty plan capabilities such as coordinated responding.

AutoAssign Role from On-Call

Use this action to assign the current PagerDuty on-call responder to an Incident Role in Rootly.

Choose the Incident Role

The Incident Role field determines which Rootly incident role should be assigned.To learn more about incident roles, see Incident Roles.

Choose exactly one PagerDuty lookup source

Use one of the following as the source of truth for the on-call lookup:

A Service
An Escalation Policy
A Schedule

For the clearest results, choose one source rather than trying to combine multiple sources in the same action.

Understand how escalation policy assignment works

When assigning from an escalation policy, Rootly looks up the on-call responders at the lowest active escalation level and assigns the first matching user found in Rootly.This action does not progress through the full escalation policy over time the way an actual page would.

Invite On-Call to Slack Channel

Use this action to invite PagerDuty on-call responders into Slack channels.

Invite PagerDuty on-call responders to Slack

Choose exactly one PagerDuty lookup source

Use one of the following as the source of truth for who should be invited:

A Service
An Escalation Policy
A Schedule

For the clearest results, choose one source rather than trying to combine multiple sources in the same action.

Choose the Slack channels

Use the Channels field to select one or more Slack channels to invite PagerDuty responders into.You can use:

{{ incident.slack_channel_id }} for the current incident channel
{{ parent_incident.slack_channel_id }} for the parent incident channel

Understand who gets invited

When using a PagerDuty escalation policy, Rootly invites the on-call users at the lowest active escalation level rather than every user in the full policy.This keeps the invite behavior aligned with how Rootly looks up active on-call responders.

Update PagerDuty Incident

Use this action to update an existing PagerDuty incident linked to the Rootly incident.

Reference the linked PagerDuty incident

Use PagerDuty Incident ID to specify which PagerDuty incident should be updated.Set this field to {{ incident.pagerduty_incident_id }} to reference the PagerDuty incident linked to the Rootly incident.

Update the incident details

You can update fields such as:

Title
Status
Urgency
Priority
Escalation Level

The Title field supports Liquid syntax.The Status field can also be set to auto if you want PagerDuty status behavior to follow Rootly status logic.

Add a resolution message when resolving

Use Resolution Message when resolving the PagerDuty incident.This field is useful for adding final context or outcome details to the PagerDuty incident when Rootly closes it.Liquid support for this field may vary, so test the output before relying on dynamic values in production.

Create PagerDuty Status Update

Use this action to add a status update message to the linked PagerDuty incident.

Create a PagerDuty status update from Rootly

Reference the linked PagerDuty incident

Use PagerDuty Incident ID to specify which PagerDuty incident should receive the status update.Set this field to {{ incident.pagerduty_incident_id }} to target the linked PagerDuty incident.

Compose the status update message

Use Message to define what should be posted into the PagerDuty incident notes or status updates.This field supports Liquid syntax.A common pattern is to post the latest Rootly incident event into PagerDuty.

Workflow Notes

Workflow actions can be combined to page, invite, assign, and synchronize activity across Rootly and PagerDuty
Some PagerDuty actions depend on the PagerDuty plan and permissions of the connected account
Rootly links only one PagerDuty incident to each Rootly incident
Advanced teams can combine these actions with broader Rootly workflow conditions and branching logic

Alert Ingestion

Rootly can ingest supported PagerDuty webhook events as alerts. These alerts can then be used to drive incident automation, alert workflows, and incident updates in Rootly. The steps below cover configuring ingestion and the automation it drives.

Set Up the Workflow

PagerDuty events are ingested into Rootly as alerts, so the correct workflow type is Alert.

Choose the Alert workflow type

Create a new workflow and select Alert as the workflow type.

This tells Rootly that the workflow should run in response to alert activity rather than incident, action item, or retrospective activity.

Use the Alert Created trigger

Select Alert Created as the workflow trigger.

In this pattern, the workflow starts when Rootly creates a new alert from a supported PagerDuty webhook event.

Add PagerDuty-specific run conditions

Configure the workflow so it only runs for PagerDuty alerts you actually want to automate.A typical setup starts with:

Alert source is Pagerduty
Alert labels contain the PagerDuty event type you want to react to
Optional payload filtering if you need more precise matching

Configure PagerDuty alert workflow conditions

Recommended Run Conditions

PagerDuty alerts in Rootly include label values that make it easier to target specific event types without relying only on payload filtering. A common pattern is to match on the alert source first, then use action: labels to decide which PagerDuty event should trigger the workflow. You can also add service_id: if you only want the workflow to run for alerts from a particular PagerDuty service. Common examples include:

New PagerDuty incident triggered
- action:incident.triggered
- Optional: service_id:PLVWMVW
Existing PagerDuty incident acknowledged
- action:incident.acknowledged
- Optional: service_id:PLVWMVW
Existing PagerDuty incident resolved
- action:incident.resolved
- Optional: service_id:PLVWMVW
Responder added to an existing PagerDuty incident
- action:incident.responder.added

Other action: label values may also be available depending on the specific supported PagerDuty event being ingested.

Filter by Payload When Needed

If labels are not specific enough, you can add payload-based filtering. Use JSONPath to select the field from the alert payload, then compare it to a value or regular expression. This is helpful when your team only wants to react to PagerDuty events that match a certain property in the webhook payload. For example:

JSONPath: $.object.specific_field
Match value: /specific_value/i

Many workspaces start with a single payload condition plus labels. Some teams may have support for multiple payload conditions, depending on feature availability.In most cases, it is better to filter by labels first and only use payload filters where labels are not enough.

Helpful tools:

JSON Path Explorer
Rubular for Ruby regular expressions

Create a Rootly Incident from a PagerDuty Alert

Use the Create Incident action when you want a PagerDuty alert to declare a new incident in Rootly. Because this action is being driven by an alert, dynamic values use the {{ alert.<properties> }} format. If you want the new Rootly incident to stay linked to the PagerDuty incident, include a custom mapping that stores the PagerDuty identifiers on the incident.

Add the Create Incident action

Add a Create Incident action to your alert workflow.This is the action that declares the Rootly incident when the PagerDuty alert arrives.

Map the PagerDuty identifiers onto the incident

Add the following custom mapping so the new Rootly incident stays associated with the PagerDuty incident:

{
  "pagerduty_incident_id": "{{ alert.data.data.id }}",
  "pagerduty_incident_number": "{{ alert.data.data.number }}",
  "pagerduty_incident_url": "{{ alert.external_url }}"
}

Create Incident action for PagerDuty alerts

If alert grouping is enabled, Rootly skips incident creation for grouped alerts that are not the leader alert.

Update an Existing Rootly Incident from a PagerDuty Alert

Use the Update Incident action when the PagerDuty alert should modify an incident that already exists in Rootly. The most important part of this setup is telling Rootly how to find the correct incident. For PagerDuty-driven updates, the standard pattern is to match on pagerduty_incident_id.

Add the Update Incident action

Add an Update Incident action to the workflow for the PagerDuty event you want to handle.

Match on the PagerDuty incident ID

Set the match fields as follows:

Attribute to Match: pagerduty_incident_id
Attribute Value: {{ alert.data.data.id }}

Update Incident action for PagerDuty alerts

This tells Rootly which incident should be updated when the PagerDuty alert is processed.

Use Custom Fields Mapping for Richer Automation

Custom Fields Mapping lets you set additional incident attributes dynamically. This field accepts JSON with embedded Liquid, which makes it useful for incident timestamps, role assignments, and custom form fields.

Log acknowledgement time

Use this when the workflow is responding to an acknowledged PagerDuty incident:

{
  "acknowledged_at": "{{ alert.created_at }}"
}

Pair this with run conditions for action:incident.acknowledged.

Assign an incident role to the acknowledging user

You can map the PagerDuty acknowledging user back to a Rootly user by combining Liquid with custom JSON:

{% assign pd_user_email = team.pagerduty_users | find: 'id', alert.data.agent.id | get: 'email' %}
{% assign rootly_user_id = team.users | find: 'email', pd_user_email | get: 'id' %}

{
  "incident_role_assignments_attributes": {
    "0": {
      "incident_role_id": "801dd6f8-f810-4819-9c3c-e77bc7038581",
      "user_id": "{{ rootly_user_id }}"
    }
  }
}

Pair this with run conditions for action:incident.acknowledged.

Set a custom Rootly field

Example for a text field with a hard-coded value:

{
  "form_field_selections_attributes": [
    {
      "form_field_id": "e041106e-cb9a-404b-8ae1-51a1d6213a68",
      "value": "Nifty Gateway"
    }
  ]
}

Example using data from the alert payload:

{
  "form_field_selections_attributes": [
    {
      "form_field_id": "e041106e-cb9a-404b-8ae1-51a1d6213a68",
      "value": "{{ alert.data.organization.name }}"
    }
  ]
}

Replace that Liquid path with one that actually exists in your PagerDuty alert payload. Example for a single-select or multi-select field:

{
  "form_field_selections_attributes": [
    {
      "form_field_id": "e041106e-cb9a-404b-8ae1-51a1d6213a68",
      "selected_option_ids": ["option_id"]
    }
  ]
}

Alert Notes

Supported PagerDuty webhook events do not all behave the same way in Rootly
Some accepted PagerDuty events may not create an alert at all, so there may be nothing for an alert workflow to trigger from
incident.triggered alerts may be skipped if the PagerDuty incident is already linked to an existing Rootly incident
PagerDuty webhook payload structure can differ by webhook version, so always verify your Liquid paths and payload fields before using them in production

Debugging Alerts

If a workflow is not behaving as expected, open the workflow run details in Rootly by navigating to: … > View Runs > View Common errors include:

Error Type	Comment
`unknown attribute 'incident_property' for Incident.`	This usually means the incident property you are trying to set is not supported, is not enabled for workflows, or the syntax is incorrect. Verify the field name and confirm it can be set through workflows.
`unexpected token at '{ "incident_property": }'`	This means the custom mapping syntax is invalid. Make sure your JSON is complete, properly quoted, and does not contain invalid syntax.

Frequently Asked Questions

PagerDuty has incident management features too. How is this different?

PagerDuty and Rootly overlap in some areas, but Rootly provides a broader incident management experience with stronger coordination workflows, automation, retrospectives, stakeholder communications, and integrated on-call capabilities.

Should I keep using PagerDuty, or can Rootly replace it?

With Rootly On-Call, Rootly can replace PagerDuty for many teams. If you are evaluating whether to consolidate tooling, see how Rootly compares to PagerDuty.Rootly will continue to support PagerDuty for teams that want to keep using it as part of their incident response stack.

I do not use PagerDuty. Is that okay?

Yes. Rootly does not require PagerDuty. Many teams use Rootly alongside an on-call provider, but Rootly can still support incident management workflows even if your team does not use PagerDuty.

Why am I seeing 'Failed to authenticate. Reason: Invalid Credentials' when connecting PagerDuty?

This usually means the PagerDuty authorization did not complete successfully. Common causes include an inactive PagerDuty account, revoked authorization, or using the wrong PagerDuty account during setup.Re-authorize the integration and confirm your PagerDuty account is active. If the issue continues, contact support@rootly.com or use Help > Chat with Us in Rootly.

​Before You Begin

​PagerDuty Permissions

​Installation

​Set Up PagerDuty Webhooks

​Via the PagerDuty Web UI

​Via the PagerDuty API

​Smart Defaults

​Rootly to PagerDuty

​PagerDuty to Rootly

​Additional PagerDuty Settings

​Smart Defaults Notes

​Import Teams

​Workflow Actions

​Page PagerDuty On-Call

​AutoAssign Role from On-Call

​Invite On-Call to Slack Channel

​Update PagerDuty Incident

​Create PagerDuty Status Update

​Workflow Notes

​Alert Ingestion

​Set Up the Workflow

​Recommended Run Conditions

​Filter by Payload When Needed

​Create a Rootly Incident from a PagerDuty Alert

​Update an Existing Rootly Incident from a PagerDuty Alert

​Use Custom Fields Mapping for Richer Automation

​Log acknowledgement time

​Assign an incident role to the acknowledging user

​Set a custom Rootly field

​Alert Notes

​Debugging Alerts

​Frequently Asked Questions

Before You Begin

PagerDuty Permissions

Installation

Set Up PagerDuty Webhooks

Via the PagerDuty Web UI

Via the PagerDuty API

Smart Defaults

Rootly to PagerDuty

PagerDuty to Rootly

Additional PagerDuty Settings

Smart Defaults Notes

Import Teams

Workflow Actions

Page PagerDuty On-Call

AutoAssign Role from On-Call

Invite On-Call to Slack Channel

Update PagerDuty Incident

Create PagerDuty Status Update

Workflow Notes

Alert Ingestion

Set Up the Workflow

Recommended Run Conditions

Filter by Payload When Needed

Create a Rootly Incident from a PagerDuty Alert

Update an Existing Rootly Incident from a PagerDuty Alert

Use Custom Fields Mapping for Richer Automation

Log acknowledgement time

Assign an incident role to the acknowledging user

Set a custom Rootly field

Alert Notes

Debugging Alerts

Frequently Asked Questions