Alerts

Configure Rootly to ingest supported PagerDuty webhook events as alerts and use alert workflows to create or update incidents automatically.

This page focuses on the PagerDuty-to-Rootly flow: supported PagerDuty webhook events are ingested as alerts in Rootly, and those alerts can then trigger alert workflows.

Overview

PagerDuty alerts in Rootly are powered by incoming webhook events. Once PagerDuty is configured to send supported events to Rootly, those events can appear as Rootly alerts and become the starting point for automation.

This is useful when you want PagerDuty activity to drive follow-up actions in Rootly, such as creating incidents, updating existing incidents, recording acknowledgement timing, or setting incident fields automatically.

Before You Begin

Before building PagerDuty alert workflows, make sure you already have:

• A working PagerDuty integration
• PagerDuty webhooks configured so Rootly can receive supported PagerDuty events
• Familiarity with Alert Workflows in Rootly

PagerDuty events must first be received as alerts before any PagerDuty alert workflow can run.

Set Up the Workflow

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

1. 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.

2. 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.

3. 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

   

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.

1. 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.

2. 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 }}"
   }
   

   

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.

1. Add the Update Incident action

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

2. Match on the PagerDuty incident ID

   Set the match fields as follows:

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

   

   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"]
    }
  ]
}

Important 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

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.