Streamwake + PagerDuty.
Both directions — PagerDuty triggers seed Streamwake, Streamwake writes back.
PagerDuty is the first ITSM source where both directions matter. PagerDuty incident triggers reach Streamwake as investigation seeds via a signed V3 Webhook; and once a Streamwake investigator approves, escalates, or resolves, those writes go back to the same PagerDuty incident so the on-call rotation reads the entire loop on the surface they paged on.
Inbound and outbound traffic travel over PagerDuty's two production endpoints —events.pagerduty.com for the digest path that already ships, andapi.pagerduty.com for the new authenticate-then-act dispatcher that drives approve / escalate / resolve.
Inbound triggers as seeds
and outbound actions as write-back.
Sync (PD → Streamwake)
PagerDuty V3 Webhooks post every incident.triggered directly to a signed Streamwake endpoint. Every incoming PD incident lands in the audit trail with a confidence-scored classification and the remediation the agent applied, and a Streamwake Incident row is lazy-seeded when no existing row matches.
Escalate (Streamwake → PD)
A PATCH against /incidents/{id} flips the PD urgency to high on a fresh investigation no later than the human handoff; a typed note is appended to the same incident inline.
Approve (Streamwake → PD)
Governed recovery actions (cache invalidations, edge reroutes, CDN partner warm-ups) require an approval gate. The dispatcher posts the approval request as a note on the PD incident and stamps a type='approval_requested' IncidentEvent.
Resolve (Streamwake → PD)
When downstream recovery is verified, a typed REST note closes the PD incident AND fires Events API v2 event_action='resolve' against the matchingdedup_key so a PD incident originally opened via the digest cron auto-resolves on this call.
Auth, webhook URL, and signing secret
on both sides of the connection.
No OAuth flow, no app registration — the connection is a signed V3 Webhook + a per-user REST API token. Four steps to a verified test incident.
- 1
Generate a PagerDuty REST API token
From your PagerDuty account → My Profile → API Access, create a personal REST API key (20+ chars, scoped to your account). Streamwake uses it as `Authorization: Token token=<key>` for the escalate / approve / resolve dispatcher.
- 2
Generate the Streamwake inbound signing secret
From Streamwake /app/integrations, set the webhook signing secret (any 32+-char string). Streamwake stores it on your PagerDutySource row and uses it to HMAC-SHA256-verify every X-PagerDuty-Signature header against the raw request body.
- 3
Configure the V3 Webhooks tile with the rotate-token URL
In PagerDuty → Integrations → Generic Webhooks V3, add a webhook pointing at `/api/v1/pagerduty-webhook?token=<routerToken>` (the routerToken is generated and surfaced once on the source card). Tick `incident.triggered`, `incident.acknowledged`, `incident.resolved`, and `incident.escalated` as the subscribed event types.
- 4
Send a test incident
Click `Send a test event` on the PagerDuty V3 tile. The Streamwake audit-trail row lights up within a few seconds, the link is created against a lazy-seeded Streamwake incident, and Approve / Escalate / Resolve become available on /app/incidents.
| Field | Owned by | Notes |
|---|---|---|
| REST API token | You | A personal PagerDuty REST API key. Never echoed through Streamwake; only a `hasApiToken` boolean is surfaced on the source card. |
| Webhook signing secret | You | A 32+-char string you generate when configuring V3 Webhooks. Used to HMAC-SHA256-verify the X-PagerDuty-Signature header on the raw body. Never echoed back. |
| X-PagerDuty-Signature header | PagerDuty | HMAC-SHA256 of the raw request body, hex-encoded, prefixed with `sha256=`. Streamwake recomputes the MAC on receipt and rejects on mismatch. |
| routerToken (URL query param) | Streamwake | An unguessable cuid Streamwake generates once on /app/integrations. Resolves the owning tenant BEFORE HMAC verification, so probing cannot enumerate which slugs exist. |
Inbound: (userId, pdEventId) dedupes PD retries; (userId, pdIncidentId) dedupes inbound against existing links. Outbound: the resolve path uses the same streamwake-trigger:$${userId}:$${streamwakeIncidentId} dedup_key the digest cron uses for event_action='trigger' so a PagerDuty incident opened via Events API v2 auto-resolves on a Streamwake Resolve.
A real bidirectional flow,
landed in the Streamwake audit trail.
The shape of what shows up once the V3 Webhooks tile is configured: one inbound PagerDuty trigger as the incident's seed, three outbound writes (approve, escalate, resolve) stamped against the same Streamwake incident row.
CMAF edge brownout — playback failures in EU-West
- PagerDuty incident
- PD-INV-91827
- Streamwake incident
inc_8z29q3kf7- Audit cuts
- 4 (1 inbound, 3 outbound)
- Signer
- HMAC-SHA256
- inbound · incident.triggered
CMAF edge brownout — playback failures in EU-West. Severity flipped to sev1 (PD urgency: high).
just now - action · approve
Streamwake approval requested: reroute EU-West traffic to the secondary CDN edge.
1 min later - action · escalate
PagerDuty urgency flipped to high. Audit trail row stamped with severity=sev1.
2 min later - action · resolve (REST note + Events API v2)
Edge roll completed; rebuffer ratio returned to cohort baseline. PD auto-resolved via matching dedup_key.
9 min later
Bidirectional, signed both ways. Every inbound webhook arrives as POST /api/v1/pagerduty-webhook?token=<routerToken> with X-PagerDuty-Signature verified against the raw body. Every outbound action (escalate / approve / resolve) carries the canonical PagerDuty Authorization: Token token=… header and stamps a lastAction on the link row.
Run the Free Stream Check,
see the audit trail PagerDuty feeds.
Paste a playback URL into /stream-check — five checks in under a minute, no login. Pair it with the Book-a-demo block below for a guided walkthrough of the V3 Webhooks tile setup, the HMAC signing convention, and the approve / escalate / resolve write-back on your PagerDuty account.
Book a 20-minute walkthrough on your PagerDuty account.
We're happy to walk through the V3 Webhooks tile setup, the HMAC signing convention, the REST API auth shape, and the approve / escalate / resolve dispatcher against a real PagerDuty service. Drop your details below and we'll follow up within 1 business day.