How to Automate PagerDuty Incident Triage with n8n and Claude (Step by Step)

If you're on call, you know the worst part isn't the hard incidents — it's the first five minutes of every page, half-awake, trying to figure out what's even on fire from a wall of raw metrics.

In this guide I'll show you how to wire up an AI triage assistant that, the moment a PagerDuty alert fires, posts a clear, structured summary to your Slack incident channel — using n8n (a free automation tool) and Claude (Anthropic's LLM). It runs on your own infrastructure, costs a couple cents per incident, and needs no server or database.

What we're building
PagerDuty alert → n8n webhook → Claude → structured triage in Slack

The triage message answers, in seconds:

• What's on fire, in plain English
• Likely blast radius
• What changed recently (deploys, config)
• A severity sanity-check
• Suggested first moves (reversible-first)
• A confidence level and the biggest unknown

Prerequisites (all free to start)

1. An n8n account (free self-hosted, or a Cloud trial)
2. An Anthropic API key (pay-as-you-go, ~1–2¢ per incident)
3. A Slack incoming webhook for your incident channel
4. PagerDuty (a free developer account works for testing)

Step 1 — Receive the alert
Add a Webhook node in n8n. This gives you a URL you'll point PagerDuty's v3 webhooks at. It fires every time an incident triggers.

Step 2 — Normalize the payload
A Code node pulls the useful fields out of PagerDuty's payload — title, service, urgency, the alert body, and any recent-deploy info — into a clean object. Real triage quality depends on how much context your alerts carry, so it's worth enriching your Alertmanager annotations with deploy + metric details.

Step 3 — Call Claude
An HTTP Request node calls https://api.anthropic.com/v1/messages. The system prompt is where the magic (and the discipline) lives. The key instructions that make an SRE trust the output:

• Write for experienced engineers who punish confident nonsense.
• Say "insufficient signal" instead of guessing.
• Never fabricate a runbook URL, metric, or root cause. Root cause is a hypothesis to check, never a conclusion.
• Mark inferences as inferences. That "don't bluff" framing is the single biggest difference between a genuinely useful triage bot and a generic AI-wrapper that hallucinates diagnoses.

Step 4 — Post to Slack
A final HTTP Request node posts the formatted message to your Slack incoming webhook. Add a fail-safe: if the Claude call errors, post the raw alert instead, so an incident is never silently dropped.

The result
A P1 fires. Within seconds your channel shows: "Postgres connection pool near exhaustion (198/200), causing POST /charge latency and error spikes," the likely blast radius, the suspicious recent deploy, and three reversible-first actions — with the AI honestly flagging what it isn't sure about.

Going further: auto-drafted postmortems
The same pattern extends to the end of an incident: feed Claude the incident + timeline when it resolves, and have it draft a blameless postmortem — contributing factors written as questions for the team, hypotheses labelled not confirmed, an action-items table. You edit and publish; the blank page is gone.

Get the workflows
I've packaged both of these — production-ready triage and postmortem workflows, the tuned prompts, and a setup guide with screenshots — as the Incident-Ops Kit. There's a free single-workflow version to try first: https://nightshiftlabs.gumroad.com/l/pvynan — and the full kit is linked inside the download.

If you build your own version from this guide, I'd love to hear how it goes.