A PagerDuty API key lets whoever holds it read and change the data behind your on-call setup: services, escalation policies, schedules, incidents, users and integrations. The key acts with the permissions of the account or user it belongs to. An attacker can resolve open incidents so nobody is paged, reroute escalation policies so alerts go nowhere, or add an integration that receives your incident details. Alerts are only useful while the setup behind them is trusted, so treat this key as a control over how your team learns about outages.
Check your GitHub account for leaked secrets — free
- Provider
- PagerDuty
- Severity
- High
- Impact
- SaaS account access and billing
- Checked live by LeakWatch
- No
What a PagerDuty API Key looks like
A PagerDuty REST API key is a short string with a fixed shape: one lowercase letter, a plus sign, nine letters, a hyphen, two lowercase letters, another hyphen, and five letters or digits. The masked form looks like this:
x+…XXXX PagerDuty REST API key (masked)
The shape alone is not enough to identify it. The rule relies on the word pagerduty appearing within about 40 characters before the value, so a key in a config file next to a pagerduty setting or header is the usual case. Keep in mind that PagerDuty has two kinds of REST API keys. General access keys belong to the account and are managed by admins. User tokens belong to one person and carry that person’s permissions. Both are handled the same way in this guide, but the place you delete them from is different.
How PagerDuty API keys get leaked
- Monitoring and alerting scripts. A script that opens an incident or pulls on-call data, with the key typed directly into the code.
- Terraform and infrastructure code. The PagerDuty provider configured with the key in a provider block or a variables file that was committed.
- Environment files and CI variables. A key written into a
.envfile, a Helm values file or a pipeline definition that is shared with other repositories. - Chat and ticket threads. A
curlcommand pasted with theAuthorizationheader to debug an integration. - Build logs. A pipeline step that echoes its configuration, including the header or the variable it used.
What to do in the first hour
- Create a replacement key first. Sign in to PagerDuty. If the key was a general access key, an admin opens Integrations, then Developer Tools, then API Access Keys, and creates a new key. If it was a user token, the owner opens their profile, goes to User Settings, and creates a new token in the API Access section.
- Deploy the new key to the secret store or CI variables that use it. Run one read request, for example listing the services, to confirm the replacement works.
- Remove the exposed key from the same place. Disabling a general access key blocks its use but keeps it, so delete it when you are sure it is not needed. Deleting is permanent.
- Review the incident history. Look at incidents opened, acknowledged, resolved or reassigned since the exposure, especially any you did not expect. Check the audit records of your account, which show changes to services and users.
- Check escalation policies and services. An attacker who could edit them could remove a responder or send pages nowhere. Compare each escalation policy and its schedules with the version you expect.
- Review integrations. Look at the list of services and their integrations, and remove any webhook or integration endpoint you do not recognize.
- Clean the repository. Remove the value from the code, rewrite history if needed, and look for other secrets stored next to it. See I accidentally pushed an API key to GitHub.
Not sure what else leaked? Run a free scan.
Revoke it at PagerDuty
General access keys are managed by an account admin under the API access keys section of Developer Tools. User tokens are managed by the owner under the API Access section of their User Settings. Find the key by its description and remove it. Use the API keys page as the starting point, and if the menu names have changed, look for the section that lists REST API keys in your account. Once a key is removed, requests that use it fail, so do the replacement and deployment first.
How LeakWatch detects it
The rule is called PagerDuty API Key. It looks for the word pagerduty, followed by up to about 40 characters of anything, and then a value in the fixed shape described above: one lowercase letter, a plus sign, nine letters, a hyphen, two lowercase letters, a hyphen and five letters or digits. The value must sit on word boundaries. A value with a different shape, or one that is not close to the word, is not reported. The severity is high. This type is not checked live: LeakWatch does not send any request to PagerDuty with the key it found.
LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.
FAQ
Can someone resolve my incidents with this key?
Yes, if the key’s account or user has permission to change incidents. The attacker could resolve or reassign them, which hides real problems from your responders. Check the incident history for the period since the exposure and reopen anything that was closed without a reason.
Is a user token less dangerous than a general access key?
It can be, because a user token has only that person’s permissions. It is still a credential that can change incidents and services they can reach, so revoke it the same way. Check which permissions that user has before you decide how far to look.
Will PagerDuty warn me when a key is used from somewhere unexpected?
Do not count on it. Check the activity yourself, and rely on the replacement and removal steps above rather than on an alert.