What InfraNest can see and do in PagerDuty

This article explains exactly what InfraNest can see and do in your PagerDuty account, what it stores, for how long, and how to remove access. It's written for whoever approves apps on your PagerDuty account, and for your security team.

Overview

• InfraNest connects to PagerDuty in two ways: a one-click sign-in connection with limited permissions, or a pasted integration key with no sign-in at all.
• It only reads and changes what's listed below — nothing more.
• You can see exactly who connected the account, and disconnect at any time.

What InfraNest can do in PagerDuty

With one-click connect, you authorize InfraNest in PagerDuty. InfraNest uses that access for exactly these things, and nothing else:

• Read who authorized it — to show who connected the account and confirm the sign-in still works.
• List your services — so you can choose which ones to page.
• Read your role and the teams that own a service you choose — to tell you before you finish setup whether your role can add the integration and create the webhook.
• Add an InfraNest Events API v2 integration to the services you choose, and remove it again — this is how a monitor alert pages a service.
• Create, check and remove one account webhook — so acknowledgements and resolutions in PagerDuty reach InfraNest.
• Create, change and remove maintenance windows on the services you switch it on for — so InfraNest maintenance also pauses those services in PagerDuty.
• Read who is on call for the services you page — to show who is on call on services, monitors and incidents, and for on-call placeholders in automations.
• Read incidents, users, escalation policies and priorities — to target an incident and offer account-backed choices in the automation builder.
• Read an incident's alerts, and find an open incident by its key — to tell which InfraNest incident a PagerDuty update is about.
• Add notes, escalate or reassign incidents, set priority or urgency, request responders and snooze — only when an automation you configure commands it.
• Add notes to incidents InfraNest raised, and read a shortened note — only on services with Sync notes on.

InfraNest's PagerDuty app asks for exactly these permissions and no others. A PagerDuty Admin or Account Owner installs the app once and sees this list before installing; after that, anyone on your account can connect, and PagerDuty shows them the same list on its authorization screen.

InfraNest never edits escalation-policy definitions, schedules, users or teams. An incident automation can assign an existing policy or user and request responders; it does not change those account resources. Setup and disconnect only change or remove integrations and webhooks InfraNest recorded as its own, by their PagerDuty ID. A resource that merely has the same name is left alone.

With an integration key you paste yourself, InfraNest can only raise, acknowledge and resolve events on that one service, and send it change events (deploys and the changes InfraNest makes, shown under Recent changes). An integration key has no other powers.

NoteYou can see this same permission list anytime on the PagerDuty account in InfraNest, under Connected by, along with the name of the person who signed in.

What uses your sign-in

Only these InfraNest features use your PagerDuty sign-in:

1. Setting up: connecting, choosing or removing a service, and turning on alerts or two-way sync.
2. Running Check setup, and any repairs it makes.
3. Disconnecting: removing what InfraNest created in PagerDuty.
4. Pausing services in PagerDuty during your maintenance windows.
5. Showing who is on call on services, monitors and incidents, and in automations.
6. Incident automation actions and their account-backed pickers.
7. Incident notes: adding InfraNest updates as notes, and reading a long PagerDuty note in full.

Paging and acknowledgement/resolution two-way sync do not use the sign-in. Alerts reach PagerDuty with each service's integration key, and acknowledgements, resolutions and notes come back through the signed webhook.

If the person who connected leaves

1. Paging and two-way sync keep working.
2. The sign-in-based features stop. The PagerDuty account in InfraNest says PagerDuty no longer accepts this sign-in and lists who it belonged to. InfraNest stops using the sign-in until someone connects again.
3. Someone who can manage integrations clicks Connect again on the account and signs in to the same PagerDuty account. Services, alerts and automations stay as they are.
4. A sign-in to a different PagerDuty account is refused, and nothing changes.

TipTo avoid any gap, have someone else use Connect again before the person leaves. Check setup also checks the sign-in and shows whose it is.

An account connected with a pasted integration key has no sign-in, so none of this applies to it.

What InfraNest sends and receives

Sent to PagerDuty, on each page: a summary, the monitor or record it is about, its component, group and class, InfraNest's impact and source for the incident, a link back to InfraNest, and your own custom fields on that server, domain or certificate, so your PagerDuty rules can route on them. Only fields you created in InfraNest are sent; remove a field's value to stop sending it. With Send changes on, the changes listed in the paging settings help article. With Sync notes on, updates posted on the incident, with the author's name.

Received from PagerDuty, through the signed webhook: what happened to an incident (acknowledged, resolved, escalated and so on), who did it, the incident's title, service, priority and assignees, and the text of notes and status updates. InfraNest keeps note text only on services with Sync notes on, and publishes status updates only where you switched that on.

InfraNest sends nothing else to PagerDuty. Your PagerDuty data goes somewhere else only when one of your own automations sends it there — for example, a rule that posts PagerDuty notes to Slack.

What InfraNest stores

• The connection: the PagerDuty account name, its region (United States or European Union), your sign-in tokens, and the name and email of the PagerDuty user who signed in.
• For each service you page: its PagerDuty ID and name, the ID of the InfraNest integration on it, and its integration key.
• For updates coming back: the webhook's signing secret and the address PagerDuty sends to.
• To match incidents: the PagerDuty incident ID next to the InfraNest incident it belongs to.
• For maintenance: the ID, services and times of each PagerDuty maintenance window InfraNest created.
• Who is on call: nothing is stored. Names and emails are kept in memory for at most five minutes, then forgotten — never written to the database, activity records or logs.
• Builder choices: user, escalation-policy and priority IDs and names are cached for five minutes per connection and sign-in.
• Notes created by automations: a connection-scoped fingerprint of the incident and returned note ID is cached for seven days, so that exact note does not start another automation. Note text is not stored in this fingerprint.
• Status updates: on services with Publish PagerDuty status updates on the status page on, a status update's text becomes an update on the InfraNest incident and its status page, and is not stored anywhere else. This switch is off by default for every service.
• Incident notes: on services with Sync notes on, the text and author's name of each note copied from PagerDuty, and the ID of each note InfraNest added in PagerDuty. Shown only inside InfraNest, never on a status page, and deleted with the incident.
• Activity records: each call to and update from PagerDuty is logged with its outcome, so you can see why something did or didn't happen. Secrets are removed before anything is logged.

WarningSign-in tokens, integration keys and the signing secret are encrypted with a key that belongs to your organization alone. They are never shown again after you connect, not in the app and not through the API.

How long it is kept

• Connection, services, keys, tokens and signing secret: until you disconnect, or remove the service.
• Activity records: 14 days for successes, 60 days for failures.
• Automation events started by PagerDuty: 45 days.
• Audit log of changes to the connection: your plan's audit retention (7, 30 or 365 days).
• Incident matches: as long as the InfraNest incident exists.
• Who is on call: at most five minutes, in memory only.
• Notes copied from PagerDuty: as long as the InfraNest incident exists.

Where it is kept

InfraNest stores your data in Germany, in ISO 27001-certified data centres, with off-site backups inside the EU. InfraNest talks to the PagerDuty region your account is in — the United States or European Union addresses, matching your account's region. PagerDuty's own copy of your incidents stays wherever PagerDuty hosts your account.

AI

InfraNest does not send your PagerDuty data, or anything it sends to PagerDuty, to an AI model, and does not use it to train one.

Remove access

1. Remove one service on the account: InfraNest deletes its integration from that service in PagerDuty, deletes the alert destination it created for it, and forgets the key.
2. Disconnect: InfraNest removes its webhook, every integration it created, and the maintenance windows it created that haven't started yet, from PagerDuty. It deletes the alert destinations it created and the stored sign-in, keys and secret. Automations that used the account are switched off, not deleted. Activity and audit records then age out on the schedule above.
3. Delete your InfraNest account: when the deletion becomes final, your organization's encryption key is destroyed, which makes every stored secret unreadable everywhere, including in backups.

Destinations you created yourself, and anything InfraNest did not create in PagerDuty, are never removed.

Security

Updates from PagerDuty are only accepted with a valid PagerDuty signature, checked on the exact bytes received before anything is read from them. Each PagerDuty account connected to InfraNest has its own webhook address and signing secret. Repeated and replayed deliveries are ignored.

Read more on the InfraNest security page, in the privacy policy and the data processing agreement. Report a security issue to security@infranest.io.