When a production service fails at 3 AM, the gap between detection and
response shrinks to seconds. This guide builds a complete Slack +
PagerDuty incident alert pipeline in n8n—five nodes, zero manual
triage. A monitoring webhook (Prometheus, Datadog, Grafana) hits n8n; a Code
node normalises the alert and classifies severity; the PagerDuty node creates
an incident via the native integration’s 9 distinct actions; a Slack node
posts a formatted message to the on‑call channel using Send and Wait
for Response to pause execution; and an escalation branch re‑routes
to a manager or next engineer if no acknowledgement arrives within a
configurable timeout [1]
[2].

How do you receive alerts from monitoring tools with a Webhook trigger in n8n?

Add a Webhook node as the first node in the canvas.
Configure it to listen via POST with JSON
response format. Activate the workflow, then copy the Production
URL. Configure your monitoring tool—Prometheus AlertManager via
webhook_configs, Datadog via Integrations → Webhooks, Grafana
via Alerting—to POST alert payloads to this URL. Every incoming payload
becomes available under $json.body downstream.
[2]
[6]

For Prometheus AlertManager, set
send_resolved: true in alertmanager.yml so n8n
also receives notifications when an alert clears. For PagerDuty
as the source (when incidents originate in PD and flow into n8n), configure
a Generic Webhooks (v3) integration under Services → Your Service →
Integrations → Add Integration and point the webhook URL to n8n.
The PagerDuty community trigger node
(n8n-nodes-pagerduty-trigger on jsDelivr) enables
receiving PagerDuty incident.triggered, incident.
escalated, and incident.resolved events directly inside
workflows without polling [7].
For the six‑layer HMAC security chain that validates sender identity,
payload integrity, and request freshness before disaster‑response logic
runs, see the complete
n8n Webhook Node Security guide.

How do you parse and normalise alert payloads with a Code node for severity routing?

Place a Code node immediately after the Webhook, set to
Run Once for All Items (default). Write a JavaScript function
that extracts the alert name, severity, description, source instance,
and timestamp from the incoming JSON payload, then maps these into a flat
object with consistent keys regardless of which monitoring tool originated
the alert. Determine whether the alert fired during business hours vs.
after‑hours.
[2]
[6]

The Code node extracts fields such as alertname,
severity, and instance from Prometheus payloads;
title, alert_type, and body from
Datadog; and title, state, and message
from Grafana. It also calculates how long the alert has been active in
minutes and tags the event with isBusinessHours for downstream
routing. For PagerDuty‑sourced incidents, a typical webhook payload
includes event.event_type, data.id,
data.title, data.urgency, and
data.body.details. For more Code node transformation patterns,
see the
n8n Code Node Transformation guide.

How do you create and manage PagerDuty incidents from n8n using the native node?

The PagerDuty node provides 9 distinct actions across four
resource types: Incidents (create, get, get all, update),
Incident Notes (create, get all), Log Entries
(get, get all), and Users (get). To connect, generate an API
key in PagerDuty under Integrations → API Access Keys, then paste it into n8n
credentials. For incident creation, select the Incident → Create action,
then map the normalized alert fields from the Code node into the Title,
Service ID, Urgency, and Details fields.
[3]
[8]

The Create Incident action requires Title (from the alert
name), Service ID (hard‑coded or from a workflow variable),
and Urgency (mapped from severity: critical → high,
warning → low). The Details field accepts a
JSON object—include the alert description, source instance, and triggering
threshold. Once created, the node returns an Incident ID
that can be used in downstream nodes for acknowledgement or resolution.
For the full 6‑stage automation that moves incidents from triggered →
acknowledged → resolved without a human clicking in the PagerDuty UI, use
additional PagerDuty nodes with the Update action and the Incident ID from
the creation step [3].
For AI‑powered incident analysis, the Swrly incident response template
connects a PagerDuty event trigger to an AI agent that analyzes the alert,
pulls context, suggests runbook steps, and routes the enriched alert to
the correct Slack channel [1].
For the complete incident lifecycle automation guide, see the
n8n Error Handling Nodes guide.

How do you post a formatted Slack notification and wait for engineer acknowledgement?

The Slack node in n8n supports 44 distinct actions across
channels, messages, files, reactions, users, stars, and user groups. For
incident alerts, use the Send and Wait for Response
operation (found under Human Review) — it sends a message with approve/
decline buttons to the target Slack channel and pauses the
entire workflow until a designated team member responds
[4]
[9].

The Slack node requires OAuth 2.0 credentials with at minimum the
chat:write scope. For the Slack Trigger node (listening
for events), an API Access Token is required instead. Upstream, a Set node
builds the message body by concatenating fields from the Code node and
PagerDuty response. A typical incident alert reads: 🚨 “Incident #426
triggered — CPU usage critical on prod-web-01 (Severity: critical) —
Acknowledge below.” For rich formatting, the Slack Block Kit Builder
generates interactive messages with buttons and dropdowns. When using the
block format, n8n’s Slack node expects the complete chat.postMessage
API payload structure — providing only the blocks array without
the text fallback causes n8n to ignore the blocks
[10].
For complete credential setup including Slack app creation, permission
scopes configuration, and OAuth installation flow, see the
n8n Credential Nodes guide.

How do you escalate an unacknowledged incident to the next on‑call engineer or manager?

After the Send and Wait for Response node sends the Slack notification,
place a Wait node configured to resume after a configurable
timeout (typically 5–10 minutes). Following the Wait, add an IF
node that checks whether an acknowledgement was received: if the
user responded, proceed to update the PagerDuty incident to Acknowledged;
if the timeout elapsed without a response, route to the escalation
branch.
[6]
[9]

The escalation branch posts a second Slack message to the manager
channel or directly notifies the next engineer on the on‑call
roster, creates an escalation note on the PagerDuty incident via the
Incident Notes → Create action, and optionally updates the incident’s
Urgency to high. For automated engineer selection, the Smart On‑Call Routing
template retrieves all members from a dedicated Slack on‑call rotation
channel, checks each member’s Slack presence (active, away, offline), and
uses smart selection logic to choose the best engineer to notify
[11].
For full‑cycle observability, log every escalation event to Google Sheets
with timestamp, incident ID, escalation reason, and respondent to build
MTTA/MTTR dashboards. For the complete observability pipeline, see the
n8n for Data Pipelines guide.

What does the complete end‑to‑end incident pipeline look like from webhook to resolution?

A production‑grade incident pipeline chains six stages:
(1) Webhook receives the alert payload from any monitoring
tool; (2) Code node normalises the payload and classifies
severity; (3) Switch node routes critical alerts to
PagerDuty (after‑hours) and non‑critical to Slack (business hours); (4)
PagerDuty node creates the incident and returns the
Incident ID; (5) Slack node (Send and Wait for Response)
notifies the on‑call channel; (6) Wait + IF handles
acknowledgement timeout and escalation.
[1]
[2]

On resolution, a complementary workflow triggered by the PagerDuty
community trigger node listening for incident.resolved
events calculates Mean Time to Resolution (MTTR) from
incident timestamps, posts a resolution summary to the same Slack channel,
and updates the original message with a ✅ reaction. For webhook security,
the production‑grade Secure Webhook community node
(@prokodo/n8n-nodes-secure-webhook) bundles HMAC/JWT auth,
replay protection, IP allow/deny (CIDR), per‑IP rate limiting, mTLS header
checks, and Redis HA support into a single hardened trigger [12].
For the complete security hardening guide combining HMAC signatures, auth
headers, IP allowlisting, and defense‑in‑depth strategies, see the
n8n Webhook Node Security guide.