- If you just installed the app, try a hard refresh in your browser, or log out and back in again, as the left menu may just not have been reloaded after the install process. This is the most common issue.
- Make sure the PagerDuty app has been added to your current instance from the [ServiceNow store] (store.servicenow.com).
- Install the app to your current instance by going to System Applications, selecting Applications, and clicking the Downloads tab.
Check to see if you have any plugins that could prevent the installation from succeeding. We've seen one instance where a customer had a plugin installed that tried to encrypt each attachment within ServiceNow, which lead to the install process of the PagerDuty app looking like it succeeded but in reality it failed, so they couldn't find PagerDuty in the left-hand navigation menu.
Check that the REST API connection by going to PagerDuty → Configuration → Test REST API Connection. Check that the conditions for triggering are met.
See “When is an incident sent to PagerDuty?”, above.
Most synchronization of data and events from PagerDuty to ServiceNow happens through webhooks sent from PagerDuty to ServiceNow. For this reason, if you notice incidents are not updating or getting created from PagerDuty, the webhook import process is what will need to be examined.
To test all settings, go to PagerDuty → Configuration → Test ServiceNow User Authentication. You should see the message:
x_pd_integration (PagerDutyTest): ServiceNow user authentication test successful (200)
If you see the following instead:
x_pd_integration (PagerDutyTest): ServiceNow user authentication test failed (403)
- Ensure that the ServiceNow user for authentication and ServiceNow password for authentication configured in PagerDuty → Configuration → Properties are valid credentials for a ServiceNow web service access user
- Ensure that the password is consistent between the user and the setting in the PagerDuty Configuration properties.
- Ensure that the user for webhook authentication has the following roles:
If the password or username have changed in ServiceNow, you must also update the credentials in the ServiceNow extensions on your PagerDuty services. Alternately, in all versions 3.5 and later, you can delete the extensions, set the value of the PagerDuty Webhook field to blank in your provisioned assignment groups and configuration items, and then re-provision them.
Check that the URL in the extensions is correct. The host it points to should be the same subdomain of ServiceNow as the one that you have integrated with PagerDuty.
If you have provisioned your services and webhooks in PagerDuty from a development or staging instance of ServiceNow, you will need to update your extension URLs to reflect your production instance of ServiceNow, or the bidirectional integration will not work, because webhooks would in this case be sent to the development/staging instance of ServiceNow.
Make sure the escalation policy is assigned the incident in PagerDuty, whose corresponding incident in ServiceNow wasn’t updated (or for which no ServiceNow incident was created), has a corresponding assignment group in ServiceNow
Because the escalation policy is assigned the incident, ensure there is an assignment group that has its PagerDuty Escalation field set to the escalation policy’s ID.
You may need to add the two PagerDuty fields to the group form or list view to view their values.
Check to see if the webhook messages have been saved in ServiceNow. In ServiceNow, go to PagerDuty → Imports → Webhook Import Rows and look for records with creation time that coincides with the time that the incident in PagerDuty was triggered, acknowledged or resolved.
Check to see if you have any custom choices set up for the State field in the ServiceNow incidents model:
- Right click on the label of the State field (i.e. that would say "New" or "Resolved"),
- Select Configure Dictionary
- Switch to Advanced view
- Go to the Choices tab and look for entries with higher numbers in the Value field.
The integration follows the same convention as the out-of-box state values of ServiceNow. Higher numbers imply a more advanced state (i.e. a 6 or higher would be done/resolved or some variant thereof). If the state of the incident that did not automatically resolve is of a higher numeric value, but the incident did not resolve, it is because it was treated as already resolved.
To correct this, you will need to modify the custom choice values that you have configured for the State field to be lower than 6, so that they are treated as an unresolved state (if they reflect that).
Automation, while powerful, can interfere with and dramatically change the behavior of the synchronization if not designed carefully. Make sure that your automation in Inbound Field Rules and your custom import map code does not set fields in a way that interferes with webhook importing. You can view more information on this in our Advanced Configuration article.
Check the user's email address in ServiceNow to make sure it matches the user's email address in PagerDuty, and that the user is provisioned.
Synchronization doesn't happen in real time but is handled whenever the incident record in ServiceNow is updated, or manually initiated by selecting Refresh PagerDuty Notes from the context menu in the ServiceNow incident header bar.
If you just upgraded to 3.1 from an earlier version, you will need to enable business rules so that note import can work properly. More info is available in the ServiceNow integration guide.
You can reenable the menu item to bring it back up and run the migration. To do this:
- Go to System Definition → Application Menus in ServiceNow.
- Search by Title for the PagerDuty menu and click its name to open and edit it when it comes up.
- Under the menu items, look for the "MIGRATE WEBHOOKS" one and check the box next to it.
- In the Actions on selected rows dropdown, select "Change active state".
- Refresh the page, go to the PagerDuty application in the system menu, and you should find the menu item.
While feedback loops can result from custom business rules and/or automation in ServiceNow, it is also possible in the integration to make the mistake of creating a webhook-powered feedback loop between ServiceNow and PagerDuty.
This can happen if there are any business rules or other automated processes that alter the assignment group of the ServiceNow incident, and caution is not exercised when manually setting the integration fields. To give a high-level overview of an example of how this can possibly happen, let us assume the following configuration:
- There is a business rule that automatically changes the assignment group to B if it is placed into assignment group A.
- Both assignment group A and B are tied to PagerDuty escalation policy Z.
The feedback loop is as follows:
- Incident changes assignment group to (or is created in) B.
- PagerDuty incident triggered and assigned to Z.
- Webhook (escalation restarted;
- Webhook import in ServiceNow assigns incident to A.
- Automation changes assignment to B.
- Loop repeats.