Safelisting IPs



PagerDuty supports safelisting IP addresses, however, we do want to highlight that this method of ensuring webhook delivery security is no longer best practice. Over the last year we have added TLS 1.2 and custom headers to our webhooks which will ensure webhooks are delivered from PagerDuty. If you are migrating away from using IP Safelisting and have questions about PagerDuty’s webhook deliverability, please contact our Support team.


The EU Service Region

Please make sure to safelist IPs resolving to the URLs corresponding to your service region (currently available regions are US and EU).

Events APIs

The PagerDuty Events APIs, which are used for triggering, acknowledging, and resolving incidents, requires that your system be able to make outbound connections to on TCP port 443 (for HTTPS). and resolve to multiple IPs, which you can find by querying the A records using dig or nslookup:

$ dig a +short 

Example Query 1 (US)

$ dig a +short

Example Query 1 (EU)

$ dig a +short

In this example, you see that the Events API (US) is accessible at the IPs,, and


To access our REST API, your system must be able to make outbound connections to and/or on TCP port 443. Our REST API only allows HTTPS connections; HTTP connections are not allowed for security. and resolve to multiple IPs as well, however these IPs will be different than the ones used for our Events API or webhooks.

Example Query 2 (US)

$ dig a +short

Example Query 2 (EU)

$ dig a +short

Taking the example of the US service region, you see that the REST API is accessible at the IPs, and


The EU Service Region

Customers using REST API-based integrations may need to safelist IPs resolving to both and


Webhooks are HTTP or HTTPS calls sent from PagerDuty to your web server on the IP and port of your choosing. The current list of IPs that our webhooks are sent from can be obtained via a HTTPS GET request to the following URL: (US) (EU)

The response will be a JSON-encoded list of IP addresses.

Example Query (US)

curl -s

Example Query (EU)

curl -s

Updating ACLs to Account for Changes


These IPs can change at any time without warning.

Please be aware that the IPs above are only examples, and do not necessarily reflect the current IPs in use. If we were to change IPs and your firewall policies were not updated, you will not be able to reach our API endpoints and/or you will stop receiving webhooks from PagerDuty.

As of this writing, there is no fixed pool or dedicated prefix in which these IP addresses reside, and whenever a host in our fleet owning a given IP address is de-provisioned, the IP address is not expected to be used again by PagerDuty.

If you are hardcoding IPs into your firewall, you can use a script to receive updates when the A records for these hostnames change, or perform lookups on the aforementioned hostnames regularly to update your configurations.

If the firewall in question is an EC2 security group, this Python script (requires boto and Python 2.7 or later to run), given an IAM secret key with adequate permissions, can automatically update the security group with the necessary IP addresses to grant access.

Jira Server Integration

If you are using the new Jira extension, depending on the service region for your account, you will also need to add the address records of or to any sort of safelist that controls network egress traffic; this integration will make API calls to PagerDuty that go directly to the hostname of your account's service region.

Updated 2 months ago

Safelisting IPs

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.