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.