n8n Error Workflow: How I Stop Finding Out Days Later

An n8n error workflow is a separate workflow that starts with an Error Trigger node and runs whenever another workflow fails. You build it once, then point each workflow at it under Options, Settings, Error workflow. Mine emails me which workflow broke, which step, and the error, then adds the failure to a to-do list Claude Code works through. One error workflow covers all of them, and a generator below writes yours.

This post contains affiliate links. If you sign up through one, I earn a commission at no extra cost to you. I only point to tools I actually use or would recommend.

I wasn’t even sure some of them were running

Before this, I didn’t know when a workflow failed. I also wasn’t sure some of them were running at all. I’d find out something broke when the thing it was supposed to make just wasn’t there, days later, and then I’d go digging through the executions list trying to work out when it stopped.

My n8n ran 1,868 times in the last 24 hours. One of those runs failed. There’s no version of me who spots one bad run in 1,868 by looking, and there are too many running to rely on me noticing without an email.

So now a failure comes to me. It lands in my inbox, and it lands on what I call mission control, which is a to-do list for Claude Code. When I say “work the queue” in chat, Claude opens the error, looks into it, and fixes it. I don’t go hunting anymore.

The one I care about a lot is the workflow that uploads my review videos to YouTube. It runs ten times a day, pulls videos out of a Dropbox folder, has Claude write the title and description, and posts them. I like to know when that one errors, because a broken upload means videos just sitting in a folder.

What does an n8n error workflow do?

It catches failures from every workflow pointed at it and tells you about them. Mine is four nodes:

1. On Workflow Error. The Error Trigger. n8n runs this whenever a connected workflow fails on its own, and hands it the details.
2. Email Jen. A Gmail node that sends me the workflow name, the step that failed, the error message, the cause, the mode, the time, and a link straight to the failed run.
3. Build Incident Row. A small Code node that packs the same details into one tidy record.
4. Create Incident Row. An Airtable node that adds that record to Claude’s to-do list as a high priority item.

141 of my 213 workflows point at it, and that includes every workflow I have switched on. Of the rest, one is the handler itself and 71 are turned off: old tests, a stack of workflows still called “My workflow 5,” and a few projects I parked. I need to get in there and do a clean-up.

Who is an n8n error workflow for?

It’s for you if you have more workflows running than you can watch. Two or three scheduled workflows is already enough, because a scheduled workflow fails while you’re asleep or doing something else.

Skip it, or at least don’t stop at it, if any of these is you:

• You only run workflows by hand. The error workflow doesn’t fire on manual runs. You’re already watching those.
• Your worry is a workflow that never starts. This catches runs that fail. A workflow that got switched off or a schedule that never fires doesn’t fail, so it sends nothing.
• You want it to fix things. It tells you. The fixing is a separate step, and mine happens on the to-do list.

What do you need to build an n8n error workflow?

• n8n. Any version with the Error Trigger node, cloud or self-hosted. Mine is self-hosted on a Hostinger VPS.
• Somewhere to send the alert. I use Gmail because I’m always in my inbox. Slack, Telegram and Discord all have n8n nodes and work the same way.
• A running list, optional. I use Airtable. A Google Sheet works if you just want a history of what broke.
• Claude Code, optional. Only if you want an AI to pick up the errors and work on them. The alert part works without it.

The workflow itself costs nothing extra to build. On a self-hosted n8n, it’s four more nodes on the server you already have.

How does the Error Trigger know what broke?

When a workflow fails, n8n passes the Error Trigger a bundle of details about the failure, and your alert reads from it. The catch is that the bundle isn’t always shaped the same way.

If a normal step fails, the details arrive under execution: the error message, the last step that ran, and a link to the run. If the trigger itself fails, like a Google Drive trigger that can’t reach Google, the details arrive under trigger instead, and there’s no run link at all, because there’s no saved run to link to. n8n’s own docs say so, and I still learned it the annoying way.

What failed	Where the details are	Run link?	What my first version sent
A step in the middle of the workflow	execution	Yes	The right error
The trigger at the very start	trigger	No	“unknown error”

My alert only read execution at first, so every trigger failure came through as “unknown error” with blank fields. That’s an email telling me something broke and nothing about what. The fix was a fallback in both the email and the Code node: check execution first, and if it’s empty, read trigger. The email’s error line now looks like this:

Error: {{ $json.execution?.error?.message || $json.trigger?.error?.message || 'unknown error' }}

“unknown error” is still in there, but only as the last resort now.

Setting it up, step by step

1. Create a new workflow, add the Error Trigger as the first node, and name it something you’ll recognize, like Error Handler.
2. Add your alert node after it and build the message from the trigger’s details, with the fallback above.
3. Save it. A workflow that starts with the Error Trigger doesn’t need to be published.
4. Open each workflow you want covered, go to Options, then Settings, and pick your handler under Error workflow. Save.
5. Test it with a small workflow that runs on a schedule and has a Stop And Error node, pointed at your handler and switched on. The Stop And Error node forces the run to fail. Clicking run by hand won’t set off the alert, which is the test that fools you into thinking it’s broken.

Step 4 is the one to come back to. Every workflow needs the setting, so a new one isn’t covered until you add it.

Get the generator

The generator asks how you want to hear about a failure, whether you want a running list, which workflows would hurt most if they broke, and whether you’d rather click through n8n or have Claude Code do it. Then it writes you a prompt you can paste into Claude or ChatGPT to walk you through the build, a skill for Claude Code, or both.

Both versions carry the trigger fallback and the testing step, since those are the two parts I had to figure out after the fact. Paste the prompt into a chat, or save the skill as SKILL.md in its own folder under ~/.claude/skills/.

What it doesn’t do

It doesn’t tell me when a workflow doesn’t run. Some of my workflows matter most when they don’t fire, and an error workflow can’t see a run that never started.

It doesn’t cover a workflow until I point the workflow at it. When I counted everything for this post, five workflows that were switched on had never been connected, four Seeding Serendipity affirmation and pin workflows and one affiliate workflow. If any of them had failed, I’d never have heard. They’re connected now.

It doesn’t calm down when something breaks over and over. My social image workflow shows up on the to-do list 17 times, the most of any workflow. Each failure is its own email and its own row.

And sometimes the right fix is nothing. In August, the YouTube upload workflow failed with “Forbidden, perhaps check your credentials?” from Dropbox, and a retry eight minutes later failed the same way. The alert went out, the row landed on the list, and when Claude worked the queue the next day, it checked the runs since and found nine successes in a row. Dropbox had hiccuped and sorted itself out. Claude changed nothing and left a note: if it happens again in a cluster, reconnect Dropbox. Of the 75 failures on the list since July 17, from 26 different workflows, 73 are closed.

Frequently asked questions

Try it yourself

An n8n error workflow is one Error Trigger, one alert, and a setting on each workflow, and it turns “I’ll find out eventually” into an email the minute something breaks.

Build the handler first with the generator above, then test it with a scheduled Stop And Error workflow before you trust it. After that, go through your switched-on workflows and point every one of them at it. If you want to see what happens after the alert on my end, the Claude Code to-do list post is where the errors go to get fixed.

Related reading

• The Claude Code To-Do List That Works Before I Do
• Self-Host n8n on Hostinger: I Used the One-Click Template
• n8n Vocabulary Guide

Subscribe if you haven’t already. I’ve got plenty more builds I haven’t written up yet, and they’re coming. Go forth and automate the boring stuff.