IP Allow List for User Sessions

IP Allow List for User Sessions lets account administrators restrict sign-in access to their PagerDuty account to an approved set of IP addresses and network ranges (IPv4) — for example, a corporate VPN or office network. Once an allow list is enabled, any browser or mobile app access request from an address not on the list is blocked.

Security and IT administrators at security-conscious and compliance-driven organizations use IP Allow List for User Sessions to:

• Require all PagerDuty web app and mobile app access to come through the corporate VPN.
• Close the gap where high-privilege accounts can log in with a username and password from any network, bypassing the network controls enforced by single sign-on.
• Meet internal security policies and compliance requirements for network-layer access control, with an audit trail of every configuration change.

You configure and manage the allow list entirely through the PagerDuty REST API. There is no web app interface for it at this time. The IP Allow Lists API reference is the source of truth for how to create, retrieve, update, and delete an allow list, including all paths, parameters, and validation rules.

User Permissions

The authentication and authorization requirements for managing an allow list are documented in the IP Allow Lists API reference.

Enforcement is account-wide. Once an allow list is enabled, it applies to every user on the account regardless of role, including Account Owners.

Create an IP Allow List

An account has at most one IP allow list, containing up to 100 entries by default. To raise that limit, contact PagerDuty Support.

Each entry is a single IPv4 address or a CIDR range, and each entry can carry a description. Use descriptions to record what each entry covers, for example "Toronto office" or "Corporate VPN egress".

Create and retrieve the allow list using the operations in the IP Allow Lists API reference.

Update an IP Allow List

Use the update operation in the IP Allow Lists API reference to change the allow list's entries or its enabled state.

The API enforces validation guardrails that protect you from creating an unusable configuration. The reference documents those rules.

Disable or Delete an IP Allow List

Disabling and deleting an allow list are separate operations with different outcomes:

• Disable — enforcement stops immediately, and the allow list and all of its entries are kept. Use this to pause enforcement — during an office network change, for example — without losing your configuration. You can enable the allow list again at any time.
• Delete — the allow list and all of its entries are permanently deleted, and enforcement stops. To use the feature again you must create a new allow list from scratch.

Perform both operations using the IP Allow Lists API reference. Deletion is recorded in the audit trail.

Core Concepts

What the Allow List Enforces

When an allow list is enabled, requests to the PagerDuty web app and mobile app from an IP address that does not match any entry are rejected. A blocked person can still reach the sign-in screen at identity.pagerduty.com, but cannot access the web app or mobile app afterward.

The following are not affected by the allow list:

• REST API requests
• Events API traffic
• Webhooks and integrations

What Blocked Access Looks Like

Anyone connecting from an IP address that is not on the allow list receives a generic 403 Forbidden response:

• Web browser: a generic page reading "You don't have permission to access this resource."
• Mobile app: a generic error that may appear as a session-expiration prompt — re-logging in will not resolve an IP block.

The response deliberately does not mention the IP allow list. Naming the allow list would disclose the account's security configuration to an unauthenticated caller, so the response stays generic.

The practical consequence is that a blocked person cannot diagnose the problem from the error message. Tell everyone on your account which networks are approved. You can also contact PagerDuty Support to confirm whether a specific person is being blocked, and from which IP address.

Avoiding Lockout

If an allow list does not cover an administrator's own IP address, that administrator loses web app and mobile app access along with everyone else on the account.

Because the allow list does not apply to the REST API, a REST API key can always be used to update the allow list — to add the missing IP address, or to disable the allow list — and restore access, even when every administrator is blocked from the web app. Treat a REST API key as your recovery path:

• Create a REST API key and store it securely before you enable an allow list. If your only API key is lost or deleted while every administrator is blocked, you cannot recover access on your own.
• Verify that your administrators' networks — office and VPN — are covered by an entry before you enable the allow list.

The API's validation guardrails prevent some lockout mistakes, but they cannot prevent all of them. Entering the wrong CIDR range for your own network, for example, still locks you out of the web app and mobile app — though you can recover on your own with a REST API key, as described next.

Audit Trail

Every allow list change — creation, update, and deletion — is recorded in the PagerDuty Audit Trail, including who made the change, how it was made, and what changed, such as state changes and entries added or deleted.

Retrieve them account-wide using List Audit Records with the root_resource_types[]=ip_allow_lists filter, or for a single allow list using the list-audit-records operation in the IP Allow Lists section of the API reference.

FAQ