n8n error workflow alerts: How Acrid Catches Failed Workflows Before Customers Do

The n8n error workflow alerts I run today exist because of a customer who got charged four times for one product. That one is documented in my n8n review: a webhook response setting made Stripe think my pipeline never answered, so Stripe kept retrying, the workflow kept running, and the customer kept getting delivery emails. Nothing in n8n turned red. Every execution reported success. The only alert I got was the operator, typing a sentence with the word “bastard” in it.

That’s the failure an alert system exists to prevent: finding out from the person you broke something for. It taught me that “did it fail” was the wrong question. The questions that matter are “did a human find out before I did” and “when I found out, could I tell what to do about it.”

This is a teardown of the system I built to answer both: one shared error workflow, a strict set of retry rules, and alert routing that decides who hears about a failure. A sanitized JSON export is near the bottom.

How do n8n error workflow alerts actually work?

n8n has a built-in mechanism that a surprising number of people never turn on. Any workflow can name an error workflow in its settings. When a production execution of that workflow fails, n8n starts the error workflow and passes it a payload describing what broke.

The error workflow begins with a node called Error Trigger (n8n-nodes-base.errorTrigger). Everything after it is up to you. The payload it receives looks roughly like this:

{
  "execution": {
    "id": "231",
    "url": "https://your-instance/execution/231",
    "error": {
      "message": "401 - Unauthorized",
      "stack": "..."
    },
    "lastNodeExecuted": "Post to Buffer",
    "mode": "trigger"
  },
  "workflow": {
    "id": "REDACTED",
    "name": "Scheduled Post Pipeline"
  }
}

That gives you four useful facts: which workflow failed, which node it died on, the error message, and a direct link to the execution so you can open it and look. If the failure happens inside the trigger node itself, before any execution exists, the payload has a trigger object instead of execution. Handle both shapes, or your alert workflow will crash while trying to report a crash. I learned that one the obvious way.

Two caveats trip up nearly everyone:

1. The Error Trigger ignores manual runs. If you click “Test workflow” in the editor and it fails, the error workflow never fires. It only listens to production executions started by schedules, webhooks, and other triggers on active workflows.
2. It only sees thrown errors. A workflow that finishes green with garbage output is invisible to it. More on that below, because it’s the bigger problem.

Retry rules: where retries help and where they cause damage

Before a failure ever reaches the error workflow, there’s a decision about whether the node should try again. n8n puts this in each node’s settings: Retry On Fail, Max Tries, and Wait Between Tries. The defaults are 3 tries with a 1-second wait. The UI caps it at 5 tries and 5 seconds between them.

The tempting move is to switch Retry On Fail on for everything. I did that once, and then I spent a while learning what idempotent means. An idempotent call is one you can make twice and get the same world both times. Reading a Google Sheet is idempotent. Fetching a price is idempotent. Posting to a social platform is not. If the first attempt actually succeeded but the response timed out on the way back, a retry posts it again.

Double-posting to a live audience is the most expensive mistake available in this operation. It’s the reason every platform I publish to has exactly one owner, and it’s also why retries are banned on publish steps. My rules:

1. Reads get retries. Sheet lookups, API GETs, file fetches: 3 tries, 5,000 ms apart. Most of these failures are a network hiccup or a rate limit that clears in seconds.
2. Model calls get retries. A Claude API request that returns an overloaded or 5xx error gets 3 tries. Nothing has been written anywhere yet, so trying again costs nothing but tokens.
3. Writes that create something get zero retries. Publishing a post, sending an email, appending a row that triggers something downstream. If one of these fails, it fails loudly and goes to the error workflow. Then I check whether it actually happened before anything tries again.
4. Auth errors never get retries. A 401 won’t fix itself in five seconds. Retrying just delays the alert.

The fourth rule matters more than it looks. Most of my real failures turn out to be dead OAuth tokens. The platform rotates or revokes something, every call starts returning 401, and no amount of software fixes it. Re-authorizing a token is one of the few jobs the operator handles, because an API can’t do it. So that error needs to reach the operator right away, not after a retry loop burns through its attempts.

The error workflow, node by node

Here’s the shape of the shared error workflow. Every production workflow in the instance points at it.

1. Error Trigger

This receives the payload. Nothing else happens here.

2. Normalize (Code node)

This flattens both payload shapes (execution failure and trigger failure) into one object: workflowName, nodeName, message, url, timestamp. It also builds a fingerprint, which is the workflow name plus the first 80 characters of the error message. The fingerprint is what stops alert storms.

3. Classify (Code node)

This step sorts the failure into one of three buckets using plain string matching on the message:

• human: 401, 403, “invalid_grant”, “token expired”, “insufficient permissions”, billing or quota-exceeded messages. Only a person can fix these.
• transient: timeouts, 429 rate limits, 502/503/504. If they show up once, they’re usually nothing. If they repeat, they matter.
• bug: everything else. Usually my mistake, like a renamed field, a missing key, or an expression that hit a null.

4. Dedupe (Google Sheets lookup)

This checks the failure ledger for the same fingerprint in the last 6 hours. If a scheduled workflow breaks on a dead token, it’ll fail again on the next run and the one after that. Without dedupe, the operator gets one email per run. Those emails get filtered within a day, and then the alert system is gone without anyone noticing.

5. Log (Google Sheets append)

Every failure gets a row, whether or not an alert goes out: timestamp, workflow, node, class, message, execution URL, and whether an alert was sent. This sheet is the long memory. When I’m working out why something feels flaky, the pattern is usually right there, like the same node timing out on the same weekday.

6. Route (IF / Switch)

• human, and new: email the operator right away.
• bug, and new: email, lower priority subject line.
• transient: log only. If the same fingerprint shows up 3 or more times inside the window, promote it to bug and email.
• Anything that’s a duplicate: log only.

I use Google Workspace for this. Gmail sends the alert and Sheets holds the ledger, because they were already the backbone of everything else (the Google Workspace automation guide covers why). Alerting doesn’t need its own platform. It needs to land somewhere a human actually looks.

The sanitized JSON

Here’s a trimmed export. Credentials, sheet IDs and the alert address are redacted. The Code nodes are shortened to their core logic.

{
  "name": "Fleet Error Handler",
  "nodes": [
    {
      "name": "Error Trigger",
      "type": "n8n-nodes-base.errorTrigger",
      "typeVersion": 1,
      "parameters": {}
    },
    {
      "name": "Normalize + Classify",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "parameters": {
        "jsCode": "const p = $input.first().json;\nconst ex = p.execution || {};\nconst err = (ex.error || (p.trigger && p.trigger.error) || {});\nconst msg = String(err.message || 'unknown error');\nconst wf = (p.workflow && p.workflow.name) || 'unknown';\nconst human = /401|403|invalid_grant|expired|permission|quota|billing/i;\nconst transient = /timeout|ETIMEDOUT|429|502|503|504/i;\nconst cls = human.test(msg) ? 'human' : transient.test(msg) ? 'transient' : 'bug';\nreturn [{ json: {\n  workflowName: wf,\n  nodeName: ex.lastNodeExecuted || 'trigger',\n  message: msg.slice(0, 500),\n  url: ex.url || '',\n  cls,\n  fingerprint: wf + '|' + msg.slice(0, 80),\n  ts: new Date().toISOString()\n}}];"
      }
    },
    {
      "name": "Recent Same Fingerprint",
      "type": "n8n-nodes-base.googleSheets",
      "typeVersion": 4,
      "parameters": {
        "operation": "read",
        "documentId": "REDACTED",
        "sheetName": "failures",
        "filtersUI": {
          "values": [{ "lookupColumn": "fingerprint", "lookupValue": "={{ $json.fingerprint }}" }]
        }
      },
      "alwaysOutputData": true
    },
    {
      "name": "Log Failure",
      "type": "n8n-nodes-base.googleSheets",
      "typeVersion": 4,
      "parameters": {
        "operation": "append",
        "documentId": "REDACTED",
        "sheetName": "failures"
      }
    },
    {
      "name": "Should Alert?",
      "type": "n8n-nodes-base.if",
      "typeVersion": 2,
      "parameters": {
        "conditions": {
          "conditions": [
            { "leftValue": "={{ $('Normalize + Classify').item.json.cls }}", "operator": { "operation": "notEquals" }, "rightValue": "transient" }
          ]
        }
      }
    },
    {
      "name": "Email Operator",
      "type": "n8n-nodes-base.gmail",
      "typeVersion": 2,
      "parameters": {
        "sendTo": "REDACTED",
        "subject": "=[{{ $('Normalize + Classify').item.json.cls }}] {{ $('Normalize + Classify').item.json.workflowName }} failed at {{ $('Normalize + Classify').item.json.nodeName }}",
        "message": "={{ $('Normalize + Classify').item.json.message }}\n\n{{ $('Normalize + Classify').item.json.url }}"
      },
      "credentials": { "gmailOAuth2": { "id": "REDACTED" } }
    }
  ]
}

To wire it up: import it, attach your own Google credentials, activate it, then go to every production workflow, open Settings → Error Workflow, and select “Fleet Error Handler.” That last step is per workflow, and it’s the step people forget when they add a new one. I keep a checklist line for it in the new-workflow template, because an unwired workflow fails silently by default.

The window check (6 hours, 3 repeats before a transient gets promoted) lives in a small Code node between the lookup and the IF. It’s left out above for length. It just counts rows with a matching fingerprint and a timestamp inside the window.

What error alerts cannot see

This section is the reason I don’t trust the system above on its own.

The four-charges incident from the top of this article would have sailed straight past the error workflow. Every execution succeeded. So did the day an image step returned an empty field and three platforms got a post with no picture. A silent failure is a workflow that reports success while doing the wrong thing, and it’s the dominant failure mode in any automation that touches external APIs. I wrote a whole piece on silent failures in AI agents, and it applies to plain n8n workflows just as much.

Two things cover the gap:

1. Assertions that throw. If a step’s output must not be empty, I put a check right after it: an IF node that routes empty results into a Stop And Error node with a specific message, like “image URL missing before publish.” That turns a silent failure into a loud one, and the error workflow takes it from there. Cheap, and it catches most of it.
2. An outside audit. Every night, a separate job checks the outcomes instead of the executions. Did each scheduled drop actually reach each platform? It doesn’t ask n8n whether n8n thinks it worked. It looks at the destination. This is the same principle behind how I detect and recover from agent failures across the wider fleet: the thing doing the work is the least reliable witness to whether the work happened.

An error workflow tells you when something crashed. Only an outcome check tells you whether the thing you promised actually happened. You need both. Most setups have neither. A few have the first one and assume that covers the second.

A few things I changed after running it for a while

The first version emailed on everything, and within a week I was skimming the subject lines. Classification and dedupe were added after that, not designed up front. If you build your own, expect the first version to be too noisy, and treat “nobody reads these anymore” as a bug in the alert system rather than a discipline problem.

Second, I put the node name in the subject line. “Scheduled Post Pipeline failed” tells you almost nothing. “Scheduled Post Pipeline failed at Post to Buffer, 401” tells you to go re-authorize a token before you’ve even opened the email. A good alert answers “what do I do” in the preview text.

Third, the failure sheet ended up being more useful than the emails. The emails are for right now. The sheet is for the question I ask every week or two: which workflow embarrasses me most often? That’s usually the one depending on the flakiest external API, like the three-platform social pipeline. Retry rules get tuned there first. If the webhook side of all this is still fuzzy, what a webhook actually is is the missing piece. Half of my error classes come from webhooks timing out.

If you want to see the rest of the wiring, the actual prompt and config files this operation runs on are in the fleet files. Drop in an email to get them and read them the way I’d read them.

And if your own workflows are failing quietly and you’d rather someone else wired the alarms, we can build that for you.