Streamwake + PagerDuty.
Both directions — PagerDuty triggers seed Streamwake, Streamwake writes back.
Claim status labels: see definitions.
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.
To enable, toggle the Streamwake → Events API v2 path on /app/integrations, paste the PagerDuty Events API service-routing key for each service on the matching Streamwake ingest card, generate a per-user REST API token from your PagerDuty profile, then configure the V3 Webhooks tile so PD can post triggers back to Streamwake. Tick each event type below to see which PagerDuty surface each one hits.
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.
Four events,
three PagerDuty surfaces.
One row per event an operator will see in the audit trail. Each row names the Streamwake-side event, the PagerDuty surface it hits, and what triggers the write.
| Streamwake event | PagerDuty surface | Trigger |
|---|---|---|
sync · incident.triggered | PD V3 Webhooks → api.pagerduty.com | Subscriber on `incident.triggered` (and `acknowledged` / `resolved` / `escalated`) posts to /api/v1/pagerduty-webhook; HMAC-SHA256-signed on receipt. |
escalate | api.pagerduty.com REST · PATCH /incidents/{id} | Streamwake flips the PD urgency to `high` on a sev1 escalation and stamps a typed note on the same incident. |
approve · approval_requested | api.pagerduty.com REST · POST /incidents/{id}/notes | Governed recovery actions (cache invalidations, edge reroutes, CDN partner warm-ups) require an approval gate; typed note posted, IncidentEvent stamped type=approval_requested. |
resolve | events.pagerduty.com · Events API v2 (event_action=resolve) | Recovery verified → typed REST note closes the PD incident AND fires Events API v2 `event_action=resolve` against the same dedup_key the digest cron used for `event_action=trigger`, so a PD incident opened via V2 auto-resolves on this call. |
Each routing key feeds one service,
each service feeds one ingest card.
Streamwake creates a per-tenant routing_key for every PagerDuty service you provision. The Events API v2 path (digest cron, replay) and the V3 Webhooks path (PD → Streamwake) both round-trip through these mappings; one routing key per service, one ingest card field per routing key.
| PagerDuty service | Streamwake ingest card | Dispatch rule |
|---|---|---|
streamwake-prod-eu | EU routing key | Digest cron → events.pagerduty.com (Events API v2 · event_action=trigger) |
streamwake-prod-us | US routing key | Digest cron → events.pagerduty.com (Events API v2 · event_action=trigger) |
streamwake-staging | Staging routing key | Replay path → events.pagerduty.com (Events API v2 · event_action=trigger) |
<your PD service> | Default routing key | V3 Webhooks inbound + REST dispatcher (approve · escalate · resolve) |
The same Events API v2 routing key you paste onto the Streamwake ingest card is what the digest cron uses to event_action=trigger a PD incident, and what the resolve path uses to event_action=resolve the same incident on a matching dedup_key. V3 Webhooks (PD → Streamwake) is a separate path, signed with the webhook signing secret.
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. Five steps to a verified test incident, from a blank PagerDuty account to the audit trail row below.
- 1
Enable the Streamwake → Events API v2 path on /app/integrations
From the Streamwake PagerDuty source card, toggle the Streamwake → PD integration on. Streamwake generates a per-tenant `routing_key` for each PagerDuty service you provision, and the source card shows a single place to paste each one.
- 2
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>` on every outbound write to `api.pagerduty.com`.
- 3
Map the Streamwake routing key to a PagerDuty service
In PagerDuty → Services, create (or pick) the service you want Streamwake to drive — typically one service per environment (`streamwake-prod-eu`, `streamwake-prod-us`, …). Open the service, copy its Events API v2 integration key (the 32-char routing_key), paste it onto the matching Streamwake ingest card. Each routing key is owned by ONE service; one ingest card per routing key.
- 4
Configure the V3 Webhooks tile
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. The V3 path is what feeds PD → Streamwake; the routing keys in step 3 are what feed Streamwake → PD.
- 5
Send a test incident
Click `Send a test event` on the PagerDuty V3 tile. The Streamwake audit-trail row below lights up within a few seconds — the inbound PD trigger creates a lazy-seeded Streamwake incident — and Approve / Escalate / Resolve become available on /app/incidents, each write back propagating to the routing key you mapped in step 3.
| 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.