Tallwatch sends incident events to PagerDuty using the Events API v2. PagerDuty’s escalation policy then decides who gets paged — by app push, SMS, voice call, or all three. Setup takes about two minutes once you know which PagerDuty service should receive the alerts.Documentation Index
Fetch the complete documentation index at: https://docs.tallwatch.com/llms.txt
Use this file to discover all available pages before exploring further.
Before you start
- A PagerDuty account with the Events API v2 integration available (any paid tier, plus the Free trial).
- The PagerDuty service that should receive these alerts. A service in PagerDuty corresponds to a thing-that-can-fail. Pick or create the right one.
Step 1: Add the Events API v2 integration in PagerDuty
Open the service
In PagerDuty, navigate to Services → Service Directory, then click the service you want to receive Tallwatch alerts.
Add an integration
On the service page, click the Integrations tab, then Add an integration. Search for Events API V2 and select it.
The Events API v2 integration is sometimes called “Routing Key” inside PagerDuty’s docs. They’re the same thing. Tallwatch’s form labels it Integration key.
Step 2: Add the channel in Tallwatch
Pick PagerDuty
Select the PagerDuty kind. Give the channel a name that matches the PagerDuty service, like
PagerDuty — billing prod.How the events map
Tallwatch translates incident lifecycle events to PagerDuty event actions:| Tallwatch event | PagerDuty event_action | What happens in PagerDuty |
|---|---|---|
incident.opened | trigger | New incident, escalation policy fires |
incident.resolved | resolve | Linked PagerDuty incident is auto-resolved |
| Manual ack in Tallwatch | (none) | PagerDuty stays open; ack in PagerDuty instead |
| Manual resolve in Tallwatch | resolve | PagerDuty incident is auto-resolved |
dedup_key is set to the Tallwatch incident’s UUID, so multiple trigger events for the same incident merge into one PagerDuty incident rather than spawning duplicates.
What the alert looks like
A PagerDuty incident with:- A summary like
Tallwatch: Monitor "API healthcheck" is down (3 of 4 regions) - A severity of
errorfor opened, no severity change on resolve - The Tallwatch incident URL in the Links section so on-call can deep-link back
- Custom details listing the failing regions, the check error class, and the duration
Acknowledge and resolve from PagerDuty
PagerDuty is the only channel where the ack/resolve action syncs back to Tallwatch in v1.1 (planned). For v1, acknowledging or resolving the incident in PagerDuty silences PagerDuty’s pages but does not flip the Tallwatch incident state. Use the Tallwatch dashboard to acknowledge or manually resolve from our side.Troubleshooting
Test alert dispatched but no incident in PagerDuty
Test alert dispatched but no incident in PagerDuty
Check Tallwatch’s dispatch history for the test. If PagerDuty returned a 4xx, the most likely cause is the integration key was revoked or pasted incorrectly. Regenerate the integration in PagerDuty and update Tallwatch.If PagerDuty returned 202 Accepted but no incident appears, the service may have a deduplication suppression in place — e.g. the same incident was recently resolved, and PagerDuty is suppressing the re-trigger. Wait the dedup window out, or trigger from a different monitor.
Tallwatch shows the dispatch as `failed`
Tallwatch shows the dispatch as `failed`
Open the dispatch row to see the error. Common causes:
invalid_event_action— Tallwatch is sending an event_action PagerDuty no longer recognises. File an issue with us.- Integration disabled — someone in PagerDuty disabled the integration. Re-enable it in the service’s Integrations tab.
My PagerDuty incident isn't auto-resolving
My PagerDuty incident isn't auto-resolving
The
dedup_key must match between the trigger and the resolve. Tallwatch always uses the incident UUID as the dedup_key, so this should work automatically. If it doesn’t, the most likely cause is the Tallwatch incident was manually resolved in PagerDuty first — PagerDuty considers the dedup_key stale after manual resolve and a fresh trigger creates a new incident.Can I send Tallwatch events to multiple PagerDuty services?
Can I send Tallwatch events to multiple PagerDuty services?
Yes. Add one Tallwatch channel per PagerDuty service, each with its own integration key. Bind them to different monitors or escalation policies.
Reference
| Property | Value |
|---|---|
| Channel kind | pagerduty |
| Required config | integration_key (32-character Events API v2 routing key) |
| PagerDuty API | Events API v2 (https://events.pagerduty.com/v2/enqueue) |
| Dedup key | Tallwatch incident UUID |
| Severity | error |
| Send rate limit | 1 per 30 s per channel (queued, not dropped) |
| Retry policy | Up to 3 attempts on 5xx, then queued for the next 30-s slot |