PagerDuty Connector

Connector download

Download PagerDuty

Versioned ZIP for your CXFabric tenant.

Sign in to download Using connectors

Register the ZIP in your tenant, or add a new version if the connector is already installed.
Create or select a credential if the action requires one.
In a Draft flow, add an available action, choose its version, connect it, and map inputs.
Test the step and flow; review output and failures before activation.

See readme.md in the ZIP for settings and limitations.

Version history

v0.2.0.2Latest · 2026-10-03 · Implemented source
Improves action labels, mapping hints and connection groups while retaining the existing parameter keys, types, defaults, credentials and result contracts.
Full release notes View download
v0.2.0.1Earlier · 2026-10-02 · Implemented source
Documentation and descriptive metadata correction: capability summary first, neutral examples and no partner or personal references.
Full release notes View download
v0.1.1.0Earlier · 2026-10-02 · Starter scaffold
Historical package retained unchanged from the October 1 library release (source commit `5e2d6c623c505c75b2374b6e346a8f959e2c29c1`).
View download

Included in this version

Implemented in v0.2.0.2. Use a separate flow trigger; no webhook trigger is included.

Send a monitoring failure to PagerDuty. HTTP acceptance does not prove notification or acknowledgement.

Request recovery for the same correlation key and credential as the original trigger. Verify the resulting PagerDuty state.

Vendor API

Implementation considerations

Create an Events API v2 integration on a PagerDuty service. Store its Integration Key in a CXFabric Bearer Token credential and select that credential on both actions. The connector sends it as routing_key in JSON; a REST API token is not interchangeable.
Select the account region: US or EU. Both actions accept timeoutMs, default 8000 and allowed 1000–9000.
Reuse exactly the same dedupKey, credential and region for recovery. Repeated failures can update an open problem; a new trigger after resolution can create another incident.
HTTP 202 means the event was accepted. Notification, acknowledgment and completed resolution depend on PagerDuty configuration. On-call lookup and acknowledgment actions are not included.
Timeouts and uncertain responses are reported without automatic retries. Verify the monitoring and PagerDuty state before replaying an event.
The ZIP and 73 local tests passed. CXFabric import and live PagerDuty testing have not yet been completed.