Which PagerDuty credential does the node need?

A read-only General Access API token covers Trigger, Acknowledge, Resolve and Send Change Event, including the read-back that confirms an acknowledge or resolve applied. A scoped OAuth app needs services.read and escalation_policies.read to send events, plus incidents.read for that read-back. Only Create Incident needs a write-capable credential and a From email.

Will a check that runs every five minutes page someone every five minutes?

No. Every event carries a de-duplication key, and PagerDuty merges repeat triggers into the incident that is already open, so a condition that persists is one incident rather than one per run.

Integrations / Apps

Tell the right people

Detection is the easy half. The hard half is that what your workflow found reaches a person who can act on it. These are the apps KeeperHub speaks natively, so a workflow can page an on-call rota, post to a channel, or send an email without you hand-writing an API request.

Incident response

PagerDuty

A channel message assumes somebody is reading. PagerDuty knows who is responsible right now, escalates when they do not answer, and collapses a repeating condition into a single incident. Connect the account once, then pick a service from a dropdown on any node.

Trigger Incident

Events API v2

Page whoever is on call. Repeat triggers carrying the same de-duplication key merge into the alert that is already open, so a check that runs every five minutes raises one incident rather than one per run. The only action that can name a backup channel if the page fails to go out.

Acknowledge Incident

Events API v2

Take responsibility and stop escalation. Reads the incident back afterwards and reports its real status, because the Events API answers 202 whether or not the update applied, and offers the same short wait before sending as Resolve. A scoped OAuth app needs incidents.read for the read-back; without it the action still applies and reports the status as unknown.

Resolve Incident

Events API v2

Close the incident when the condition clears. Like Acknowledge, it reads back and offers a short wait before sending, so an update cannot overtake the trigger it was meant to close.

Send Change Event

Events API v2

Mark a deploy or a configuration change on the service timeline, so the next incident has the context of what changed just before it.

Create Incident

REST

Open an incident with a chosen escalation policy, urgency or priority. The one action that needs a write-capable credential and a From email.

What it does that an HTTP request cannot

A read-only key is enough

Listing services and resolving a routing key are reads, and the alert itself is authorised by the service’s own key. A read-only API token covers every action except Create Incident. A scoped OAuth app needs services.read and escalation_policies.read to send events, plus incidents.read for the read-back on Acknowledge and Resolve.

No credential in the workflow

The node stores a service id. The routing key is resolved server-side on every run, so an exported or shared workflow carries no credential with it.

A test that proves the service

Send a test alert runs a real trigger, acknowledge and resolve, reporting each leg separately. It uses its own de-duplication key at info severity, so it can never touch an alert a workflow opened.

PagerDuty configuration reference →Read the announcement →

Apps