Incident response tooling usually stops at "page someone and post in Slack." The harder, more valuable half, a timeline anyone can reconstruct, an MTTR number anyone can trust, and action items that actually get done, is what most teams still do manually or skip entirely. This workflow handles severity-based response automatically, builds the incident timeline as it happens rather than reconstructing it afterward, and turns postmortem action items directly into tracked tickets with owners.
Workflow diagram
flowchart TD
A[Monitoring Alert] --> B{Severity}
B -->|SEV1| C[Create Channel] --> D[Page On-Call] --> E[Status Page: Investigating]
B -->|SEV2| F[Notify Team Channel]
B -->|SEV3| G[Log Only, Ticket]
E --> H[Merge]
F --> H
G --> H
H --> I[Start Timeline Log]
J[Resolution Webhook] --> K[Status Page: Resolved]
K --> L[Calculate MTTR]
L --> M[Wait 24 Hours]
M --> N[Get Full Timeline]
N --> O[AI Draft Postmortem]
O --> P[Schedule Review Meeting]
Q[Postmortem Finalized] --> R[AI Extract Action Items]
R --> S[Create Tickets]
S --> T[Log To Registry]
T --> U[Archive Channel]
V[Quarterly Schedule] --> W[Compile MTTR Trend]
W --> X[Send To Leadership] Every branch shown here (IF/Switch outcomes) exists as a real conditional in the downloadable JSON, not a simplification for this diagram.
Severity-based response, not one-size-fits-all
Severity Classification routes SEV1 incidents through the full response, dedicated Slack channel, PagerDuty page, immediate status page update, because customer-facing outages need visible, fast action. SEV2 gets team notification without the same public-facing machinery, and SEV3 simply logs a ticket for later triage. Running every alert through the same heavyweight process either wastes response effort on minor issues or, more commonly, causes teams to route everything through informal channels because the formal process is too heavy for routine problems.
The timeline gets built during the incident, not reconstructed after
Start Incident Timeline Log begins capturing updates the moment an incident opens, so by the time Wait 24 Hours completes and AI Draft Postmortem runs, there is an actual chronological record of what was tried, what was ruled out, and when the fix landed, not a reconstruction based on people's memory of a stressful few hours.
This is the single biggest quality difference between a useful postmortem and a generic one: specific timestamps and specific actions taken, versus a vague narrative written from memory days later.
Action items that survive past the meeting
AI Extract Action Items pulls concrete, ownable tasks from the finalized postmortem document, and Create Tickets For Action Items turns each into an actual tracked ticket in Linear or Jira immediately. The most common postmortem failure mode is not a bad analysis, it is a good analysis whose action items live only in a document that nobody revisits, so the same failure mode recurs six months later.
The Quarterly MTTR Trend Schedule branch closes the loop at the organizational level: a trend line of mean-time-to-resolution over time tells leadership whether the reliability investment is actually working, something a pile of individual postmortem documents cannot show on its own.
Node-by-node reference
| Node | Type | Role |
|---|---|---|
| Severity Classification | Switch | Matches response intensity to actual incident severity |
| Start Incident Timeline Log | HTTP Request | Captures the record as the incident unfolds, not afterward |
| Calculate MTTR | Code | Objective time-to-resolution, not an estimate |
| Wait 24 Hours | Wait | Deliberate delay before drafting, for perspective and to catch delayed effects |
| AI Draft Postmortem | HTTP Request | Starting draft from the actual logged timeline |
| Create Tickets For Action Items | HTTP Request | Action items become tracked work immediately, not a forgotten list |
26 total nodes in the downloadable file, including sticky-note documentation embedded directly on the canvas.
Key logic, in code
MTTR calculation
const detectedAt = new Date($json.detectedAt);
const resolvedAt = new Date($json.resolvedAt);
const mttrMinutes = Math.round((resolvedAt - detectedAt) / 60000);
return [{
json: {
...$json,
mttrMinutes,
mttrFormatted: `${Math.floor(mttrMinutes / 60)}h ${mttrMinutes % 60}m`,
}
}];Before / after
| Metric | Before | After this workflow |
|---|---|---|
| Time to customer-facing status update | Minutes to hours, manual | Seconds after SEV1 classification |
| Postmortem accuracy | Reconstructed from memory | Built from a live-logged timeline |
| Action item completion rate | Low, tracked only in the document | Tracked as tickets with owners |
| Organizational MTTR visibility | Per-incident only | Quarterly trend reported to leadership |
Prerequisites
- n8n v1.40+ with Wait support
- PagerDuty API access
- Statuspage.io API (optional but recommended for customer-facing incidents)
- Anthropic API key
- Linear or Jira API, Slack Bot Token with channel management scopes, Airtable PAT
Common pitfalls
AI-drafted postmortems need team review before publishing
The draft is a starting point built from logged updates, which may be incomplete. The team that lived the incident should always review and correct before it is considered final.
Timeline logging quality depends on team discipline during the incident
If updates are not posted to the incident channel during the response, there is nothing for Start Incident Timeline Log to capture. This works best paired with a lightweight team norm of narrating actions as they happen.
Status page updates need a defined approval owner
For SEV1, decide in advance who can authorize customer-facing status page language, this template automates the mechanics, not the judgement call on what to say publicly.
Want this deployed, configured and monitored?
The template is free. Wiring in your real credentials, tuning the logic to your business, and keeping it running when an upstream API changes is what we do.
Get my free automation plan →Frequently asked questions
Does this work with Datadog or Grafana instead of a generic monitoring webhook?
Yes, both support outbound webhooks on alert firing, only the trigger payload parsing needs adjusting to match their specific alert format.
Is a blameless postmortem culture required for this to work?
It is strongly recommended. AI Draft Postmortem produces a factual timeline, but how a team uses that timeline, learning versus blame, is a cultural choice this workflow cannot enforce.
Can lower-severity incidents skip the full postmortem process?
Yes, route SEV3 incidents to skip the 24-hour wait and postmortem generation entirely, reserving the full process for incidents where the learning investment is worth it.