PagerDuty

Datafly Signal triggers PagerDuty incidents from Signal events using the Events API v2. Useful for waking the on-call engineer when delivery error rates spike, payments fail at the threshold, or a business-critical event needs an immediate human response.

Why route PagerDuty through Datafly Signal

• Alerts fire off the same event stream as everything else. No separate instrumentation, and no gap between what your destinations received and what PagerDuty told you about.
• Which events reach you is configuration, not code. The trigger conditions live in the pipeline alongside every other rule, so tuning what reaches PagerDuty does not require an application release.
• Alert volume is rate-limited. Signal applies the same rate limiting and retry behaviour it uses for any destination, so an incident that spikes your event rate does not flood the channel.

Prerequisites

• A PagerDuty account with at least one service.
• Permission to add integrations to that service.
• A clear sense of which events should page on-call — PagerDuty is for “wake someone up” alerts, not general notifications. For general notifications use Microsoft Teams instead.

Get your credentials

Step 1: Pick or create a PagerDuty service

1. In PagerDuty, go to Services > Service Directory.
2. Click New Service if you do not already have one for Signal alerts.
3. Set the name (e.g. Signal Delivery Alerts), an escalation policy, and an incident urgency policy.
4. Click Create.

Step 2: Add an Events API v2 integration

1. On the service page, open the Integrations tab.
2. Click Add an integration.
3. Search for and select Events API V2.
4. Click Add Integration.

Step 3: Copy the routing key

PagerDuty now shows the Integration Key (also called the Routing Key) — a 32-character hex string.

5. Copy the key.

Configure in Signal

Configuration fields

Management UI setup

1. Go to Integrations > Add Integration > PagerDuty.
2. Paste the routing_key and choose the General preset.
3. Leave consent categories at the default (essential): PagerDuty traffic is operational alerting.
4. Click Save.

API endpoint

POST https://events.pagerduty.com/v2/enqueue
Content-Type: application/json

Event mapping

General preset

dedup_key always has a value, truncated to PagerDuty’s 255-character maximum (a longer key is rejected), so repeats of one problem fold into the open alert instead of paging once per event. Payment failures are off because a declined card is routine; turn the event on only if they should open incidents.

Example: error_occurred

datafly.track("error_occurred", {
  message: "Stripe webhook handler timed out after 30s",
  error_class: "stripe.webhook.timeout"
});

{
  "routing_key": "0123456789abcdef0123456789abcdef",
  "event_action": "trigger",
  "client": "Datafly Signal",
  "dedup_key": "stripe.webhook.timeout",
  "payload": {
    "summary": "Website error reported",
    "severity": "error",
    "source": "datafly-signal",
    "timestamp": "2026-09-23T10:15:00.000Z",
    "custom_details": {
      "message": "Stripe webhook handler timed out after 30s",
      "error_class": "stripe.webhook.timeout",
      "page_path": "/checkout"
    }
  }
}

Recommended use patterns

• Delivery error thresholds. Configure a pipeline filter so events fire only when a vendor’s error rate crosses a threshold. Avoid raw error pass-through, which will drown the on-call rotation.
• Business-rule incidents. Trigger for high-value events (e.g. an order above £10,000 fails) so the right team intervenes before the customer churns.
• Payment processor outages. If you turn on payment_failed, consider mapping dedup_key to the payment processor’s name so an outage opens one incident, not one per failed payment.

Identity

Signal sends no identity data to PagerDuty: custom_details carries only the named diagnostic fields above, never the event’s property bag. Map a customer field into custom_details only if everyone on the rota may see it in the incident timeline.

Consent

The default consent category is essential. PagerDuty traffic is treated as operational alerting and fires regardless of the end-user’s marketing-consent state. This matches how most legal teams classify on-call paging.

If your governance policy requires this integration to honour marketing or analytics consent, change the consent category in the Management UI — but be aware that withdrawing consent will then silence incidents about events triggered by that user.

Verify it’s working

Step 1: Fire a test event

datafly.track("error_occurred", {
  message: "Test incident from Datafly Signal",
  error_class: "signal.test"
});

Step 2: Check PagerDuty

Within a few seconds, a new alert titled Website error reported should appear on the service, with the message in its details.

Step 3: Inspect the Signal event debugger

In the Signal Management UI, open the integration’s Recent Events tab. You should see the event with a 202 response (PagerDuty’s success code) and the full Events API v2 payload.

Step 4: Resolve the test incident

Resolve the test incident manually in PagerDuty so it does not leave on-call noise behind.

Troubleshooting

See also

• PagerDuty Events API v2 reference
• PagerDuty deduplication guide
• Microsoft Teams integration — for general-purpose channel notifications instead of paging