DocumentationWorkflowsHTTP and developer tools
PagerDuty node
Trigger an incident via the PagerDuty Events API v2 and list existing incidents via the REST API. Learn how to configure it, map inputs and outputs, run a test and resolve common errors.
8 min readUpdated
What this node does
Trigger an incident via the PagerDuty Events API v2 and list existing incidents via the REST API.
Use PagerDuty as a clearly defined step in an anymize workflow.
- Processes one input.
- Provides one output for following steps.
- Runs as a regular step in the flow.
Set up the node
- 01Open a workflow and add PagerDuty from the node catalog.
- 02Complete the required fields and map values from previous steps.
- 03Run the node with a small test record and inspect its output.
- 04Connect the successful output and activate the workflow after an end-to-end test.
Operations and modes
Choose the required function in Action. The panel then shows the relevant settings.
- Trigger incident
- List incidents
Settings
| Field | Meaning | Area |
|---|---|---|
| PagerDuty credentials | Select your PagerDuty connection from Secrets. The Routing Key and API Token have dedicated fields there: the Routing Key is enough to trigger incidents; listing incidents requires the API Token. | Protected |
| Action | Choices: Trigger incident, List incidents | Standard |
| Summary | Short summary of the incident, used as the incident's title. | Standard |
| Severity | How critical the incident is. | Standard |
| Source | Identifies where the incident is coming from (e.g. hostname or system name). Optional, defaults to "anymize-workflow". | Standard |
| Dedup key | Optional custom key to group related events into one incident. If left empty, PagerDuty generates one automatically. | Protected |
| Component | Optional: the affected component of the system. | Standard |
| Group | Optional: logical grouping (e.g. environment or cluster). | Standard |
| Status filter | Comma-separated list of status values (triggered, acknowledged, resolved). Leave empty for all open incidents. | Standard |
| Max. count | How many incidents to load at most (1,100). | Standard |
| Run once per item | Off (default): the node runs once for the whole input. On: if it receives several items (e.g. from Split Out), it runs once PER item, and {{ $json }} is that one item each time. This is how you work through a file list entry by entry. | Standard |
| If one item fails | "Skip" writes an `error` field for the failed item and keeps processing the rest, instead of losing the whole run to a single unreadable file. | Standard |
| Pause between items (milliseconds) | Wait before every run except the first. 1000 = 1 second per item. Useful when the other side would otherwise throttle you. Maximum 300000 (5 minutes). | Standard |
Inputs and outputs
| Input | Meaning | Type |
|---|---|---|
| Standard | Receives the complete result from the previous step. | JSON |
| Output | Meaning | Type |
|---|---|---|
| Standard | Makes the result available to the next step as JSON. | JSON |
This node can process lists item by item. Error handling and the delay between items are available in advanced settings.
Example and test run
Trigger a PagerDuty incident when monitoring reports a critical error: begin with a small, recognizable record. Inspect the output and only map fields that are present there.
Test-run example
{
"summary": "API antwortet mit 500ern seit 5 Minuten",
"severity": "critical",
"source": "api-prod-01",
"component": "api-gateway"
}Access and security
Before activation, review which data enters this step and what its output contains.
Store keys and credentials in the protected connection manager. Never paste them into normal workflow fields, test data or descriptions.
Troubleshooting
- No output: inspect the latest run and confirm that the previous node returned the expected fields.
- Empty variable: open the previous step output and use a field name from the real test data.
- List processed once: enable per-item execution in advanced settings.