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.
Scope of EnforcementThe IP allow list applies only to user sessions — logins to the PagerDuty web app and mobile app. It does not restrict REST API calls, Events API traffic, webhooks, or integrations.
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.
Recommended RolloutCreate the allow list in the disabled state, add and verify every entry — including the networks your administrators log in from — and enable it only after that. Before you enable the allow list, confirm your own current public IP address is covered by an entry.
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.
Deletion Cannot Be UndoneDeleting an allow list permanently deletes all of its entries. If you only want to stop enforcement temporarily, disable the allow list instead.
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.
Full Lockout RecoveryIf you have no working REST API key and every administrator is blocked, contact PagerDuty Support. Support verifies the identity and authorization of the person making the request before modifying an allow list on an account's behalf, so this path is slower than recovering on your own with an API key.
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
Why does the error not mention the IP allow list?
The generic 403 Forbidden response is intentional. A specific message would reveal the account's security configuration to an unauthenticated caller. Administrators need to tell everyone on the account which networks are approved, and can confirm specific blocks with PagerDuty Support.
Will enabling an allow list break my integrations or monitoring tools?
No. The allow list applies only to web app and mobile app user sessions. REST API requests, Events API traffic, webhooks, and integrations are unaffected.
I am locked out of the web app. How do I recover?
Use a REST API key to update or disable the allow list. REST API access is never blocked by this feature. If no working API key exists and every administrator is blocked, contact PagerDuty Support, who will verify your identity and authorization before making changes on your behalf.
Can I pause enforcement without losing my entries?
Yes. Disable the allow list. Your entries are kept and you can enable the allow list again at any time. Only deleting the allow list permanently deletes the entries.
Is IPv6 supported?
No. Entries are IPv4 addresses and CIDR ranges only.
Can I add more than 100 entries?
The default limit is 100 entries per account and can be raised on request. Contact PagerDuty Support to raise the limit.
Updated 11 minutes ago
