This page details the configuration to have Rootly respond to PagerDuty events.

​
Listen for PagerDuty Events

In order to respond to PagerDuty events, you’ll need to set up a webhook in PagerDuty so your Rootly account can receive the events.

​
Workflow Configurations

Select workflow type. Since PagerDuty events will be created into Rootly as alerts, we will need to use an Alert workflow type.
Document Image
Select workflow triggers. Alert Created will be the only option to select here. This means the workflow will initialize whenever a new alert is created in Rootly.
Document Image
Configure run conditions. Set up your workflow to only run if…
  • The alert source is from Pagerduty
  • The alert labels:
    • Option 1: contains all of the following labels (this is if you want to respond to a new PagerDuty incident being triggered)
      • action:incident.triggered
      • service_id:PLVWMVW (this label is optional - only include this if you want to respond to alerts from a specific PagerDuty service)
    • Option 2: contains all of the following labels (this is if you want to respond to an existing PagerDuty incident being acknowledged)
      • action:incident.acknowledged
      • service_id:PLVWMVW (this label is optional - only include this if you want to respond to alerts from a specific PagerDuty service)
    • Option 3: contains all of the following labels (this is if you want to respond to an existing PagerDuty incident being resolved)
      • action:incident.resolved
      • service_id:PLVWMVW (this label is optional - only include this if you want to respond to alerts from a specific PagerDuty service)
    • Option 4: contains all of the following labels (this is if you want to respond to a responder being added to an existing PagerDuty incident)
      • action:incident.responder.added
  • The alert payload has the $.object.specific_field equals to /specific_value/i
    • JSON path syntax is used to filter for a specific field from the alert payload (e.g. $.issue.fields.issuetype.name). You can preview your syntax on JSON Path Explorer.
    • Ruby regular expression can be used to specify what value to match to. You can test your regexp on this Rubular tool.
Currently, only a single payload field can be filtered on. So, try to configure your run conditions to filter by Label as much as you can before resorting to filtering by Payload.We will be exploring the possibility of supporting filtering by multiple payload fields in the future.
Document Image

​
Create Incident

The Create Incident action is used to declare an incident in Rootly. Since this action will be referencing alert data, the dynamic fields will be {{ alert.<properties> }}. Rootly does NOT automatically link alerts to the incident. You’ll need to include the following custom mapping in order to link the PagerDuty incident to the newly declared Rootly incident. 
{
"pagerduty_incident_id": "{{ alert.data.data.id }}", 
"pagerduty_incident_number": "{{ alert.data.data.number }}",
"pagerduty_incident_url": "{{ alert.external_url }}"
}
Document Image

​
Update Incident

The Update Incident action is used to update an existing incident in Rootly. Ensure that you set Attribute to Match field to pagerduty_incident_id and Attribute Value to {{ alert.data.data.id }}. These fields are required for Rootly to know which incident to update.
Document Image

​
Custom Fields Mapping

If you require more dynamic mapping of Rootly incident properties, you can input the following syntax into the Custom Fields Mapping field. Automatically log acknowledgement time.
This must be paired with Option 2 (responding to an existing PagerDuty incident being acknowledged) of the alerts workflow run conditions.
{
  "acknowledged_at":"{{ alert.created_at }}"
}
Automatically assign incident role to the user that acknowledged the PagerDuty incident.
This must be paired with Option 2 (responding to an existing PagerDuty incident being acknowledged) of the alerts workflow run conditions.
{% 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": {
         // Change below this to your role id
         "incident_role_id": "801dd6f8-f810-4819-9c3c-e77bc7038581",
         "user_id": "{{ rootly_user_id }}"
      }
   }
}
Set custom field for Rootly incident. 
//Setting Rootly text to hard-coded value
{
  "form_field_selections_attributes":[
    {
      "form_field_id":"e041106e-cb9a-404b-8ae1-51a1d6213a68",
      "value": "Nifty Gateway"
    }
  ]
}

//Setting Rootly text to value from the alert payload
{
  "form_field_selections_attributes":[
    {
      "form_field_id":"e041106e-cb9a-404b-8ae1-51a1d6213a68",
       "value":"{{alert.data.organization.name}}"
    }
  ]
}


//Setting Rootly single select or multi-select field
{
  "form_field_selections_attributes":[
    {
      "form_field_id":"e041106e-cb9a-404b-8ae1-51a1d6213a68",
       "selected_option_ids":["option_id"]
    }
  ]
}

​
Debugging

Below are common errors you might run into during your configuration process. To view the error response, you can locate the specific workflow you’re trying to debug, select … > View Runs > View.
Error TypeComment
unknown attribute 'incident_property' for Incident.Reason for error…
This means the specified incident property you’re trying to set is not an attribute you can set or the syntax is incorrect.

How to fix…
Ensure that the field you’re attempting to set is enabled to be set via workflow and that your syntax is correct.
unexpected token at '{ "incident_property": }'Reason for error…
Your custom mapping syntax is incorrect.

How to fix…
Correct your mapping syntax.

​
Support

If you need help or more information about this integration, please contact support@rootly.com or start a chat by navigating to Help > Chat with Us.