Connecting PagerDuty to n8n: receiving incidents in real time and prioritizing on-call with AI

An on-call engineer woken at 3 a.m. for an alert that resolves itself two minutes later has a real cost — not in money, but in attention: next time, the same person reacts a little slower to an actual outage. PagerDuty already routes incidents to the right person according to an escalation schedule, but it can't tell a benign latency spike apart from a failure that's about to get worse — that read stays human, and therefore slow, until it's tooled. Wiring n8n into PagerDuty lets you insert an automated triage layer between detection and notification, without touching the escalation policy itself.

Why triage before escalation

A PagerDuty escalation policy answers "who to notify, and within what window if nobody acknowledges?" — not "is this worth notifying about right now?". A poorly tuned monitoring tool that fires ten incidents a night on the same fuzzy threshold eventually desensitizes the team, exactly like any overly chatty alerting system. The right fix isn't blindly tightening thresholds at the risk of missing a real outage, but adding a contextual reading step before the notification goes out — something neither PagerDuty nor the monitoring tool does natively.

The native PagerDuty node: credential and operations

n8n ships a PagerDuty node with an API Key credential, generated from Integrations → API Access Keys in the PagerDuty dashboard (a read-only option is available if the workflow only needs to look things up). This node covers:

• Incident — create, get, get many, update (change status, reassign, change priority)
• Note — add a comment to an existing incident, get notes
• Log Entry — pull an incident's history (who acknowledged, at what time)
• User — get users and their on-call schedules

This node is enough for any management action on an incident that's already open: adding an AI-generated note with useful context, reassigning based on on-call load, or automatically closing a confirmed false positive. It's useless, though, for receiving an event — PagerDuty doesn't ship an official Trigger node, so you have to build the intake yourself.

Receiving incidents in real time with v3 webhooks

V3 webhook subscriptions (Integrations → Webhooks, at the service or account level) deliver every state change in real time to an n8n URL: incident.triggered, incident.acknowledged, incident.resolved, incident.escalated, incident.priority_updated, incident.responder.added, among other event types you can filter at subscription creation. An n8n Webhook node receives these POSTs — for HTTPS exposure and general best practices, our n8n webhook security guide covers the ground common to every incoming webhook before going further here.

Verifying the signature before processing anything

Every request carries an x-pagerduty-signature header, formatted as v1=<hash> — an HMAC-SHA256 computed over the raw request body using the shared secret, shown only once when the webhook subscription is created. A Code node recomputes this HMAC on the n8n side and compares it against the received value before even reading the incident's contents. Without this step, anyone who learns your webhook URL — guessed or leaked — could inject fake incidents into your triage pipeline.

Triaging with AI before waking anyone up

Once the signature is verified, an LLM node (a lightweight model like gpt-4o-mini or Claude Haiku is plenty) reads the incident's title, description, affected service, and — if the PagerDuty node is called alongside it — the recent incident history for that same service, to sort the alert into useful categories: genuine emergency (immediate escalation, no filtering), likely known false positive (a note added to the incident via the PagerDuty node, escalation delayed briefly until a human confirms during business hours), or degradation worth watching (a grouped digest instead of waking on-call). This pattern of classifying before notifying mirrors the one already covered for triaging Sentry alerts with AI: the underlying principle — never let an LLM decide alone on an irreversible action, only filter and enrich — applies identically here, with higher stakes since a wrongly triggered wake-up has a direct human cost.

Triggering an incident from a third-party system via the Events API v2

In the other direction, n8n can itself act as a monitoring system and trigger a PagerDuty incident — useful when one of your own workflows detects an anomaly that nothing else is watching (a sync job that fails silently, a business threshold breached). The Events API v2 (POST https://events.pagerduty.com/v2/enqueue, called via an HTTP Request node) takes a routing_key scoped to the relevant service, an event_action (trigger, acknowledge, or resolve), and a payload with summary, source, and severity. The dedup_key field deserves particular attention: successive events sharing the same value group into the same incident instead of opening a new one on every workflow run — a stable identifier derived from the nature of the anomaly (not the timestamp) avoids spamming on-call with one incident per minute for the same problem.

Logging every event

A Supabase table — PagerDuty incident ID, category assigned by the AI, action taken, timestamp — lets you measure afterward whether the automated triage is missing real emergencies or, conversely, over-filtering. Our n8n ↔ Supabase connection guide covers setting up this kind of table. Since PagerDuty retries webhook delivery if your endpoint doesn't respond fast enough, a uniqueness constraint on the event ID is still needed to avoid processing it twice — the same webhook idempotence principle already useful for Stripe or GoCardless applies here.

What research says about alert fatigue

The problem this pipeline aims to fix is documented beyond mere intuition. A 2023 study by Gelman, Taoufiq, Vörös, and Berlin, "That Escalated Quickly: An ML Framework for Alert Prioritization" (see on Google Scholar), measured the effect of a machine-learning prioritization system deployed on a real operations center: response time to actually actionable incidents dropped by 22.9%, and 54% of false positives were suppressed from the flow without major changes to existing processes — evidence that a triage layer added on top of an already-deployed alerting system, rather than replacing it, produces a measurable gain.

Common pitfalls

• Not verifying the webhook signature. Without that check, the endpoint's URL becomes the pipeline's only protection.
• Confusing the PagerDuty node with the Events API v2. The former manages incidents that already exist using an account credential; the latter creates them from the outside with a simple routing key — the two don't substitute for each other.
• A dedup_key derived from the timestamp. This generates a new incident on every workflow run instead of grouping occurrences of the same problem.
• Letting AI acknowledge or resolve an incident with no safeguard. A misclassification that closes a real incident costs more than a wrongly triggered wake-up — reserve automatic action for very low-risk categories, with an n8n Error Workflow as a safety net, and test locally first with our n8n webhook testing guide.

Summary

PagerDuty decides who to notify; it doesn't decide whether it's worth doing right now. By inserting n8n between the two — signature verification, AI classification, logging — every on-call wake-up corresponds to a decision that was actually reviewed, not just triggered by a raw threshold. If your immediate priority is tracing this kind of operational decision with a usable history, the Compliance & Audit Pack (€149) already ships the Supabase schema and reusable logging workflows for this piece. The AI Inbox Pack (€79) applies the same AI-triage logic on the inbox side, and the Complete FlowKit Bundle (€269 instead of €347 bought separately) brings all three packs together for anyone who wants to cover the whole alerting chain.