Handle Errors in Your Workflows

In the last lesson you learned to find and fix bugs in your workflows: typos in expressions, wrong field names, that kind of thing. Those are problems in your workflow. But sometimes the problem isn't your code. APIs go down. Servers hiccup for a few seconds. OpenAI returns a 500 error out of nowhere. Your workflow is fine, but the thing it's talking to isn't.

If you haven't planned for this, your workflow just stops. And you might not even notice until a client asks why something didn't happen.

I learned this the hard way. I had an error workflow set up to ping me on Discord whenever something failed. One night I woke up to a thousand Discord messages. A workflow kept failing on a schedule trigger, and each failed run sent another notification. The workflow was supposed to fetch items from a table, process them, and mark them as done. But because the processing step kept failing, it never marked anything as done, so it kept picking up the same items, failing, and notifying me again. A fun introduction to idempotency at 3am.

One thing n8n does well here: errors are visible. Each official node has built-in error handling, so errors don't get silently swallowed. You see exactly what failed and where. That makes it much easier to deal with than chasing invisible bugs in code.

Watch the video below. Michele covers the five main error handling techniques in n8n: retry on fail, continue on error, split error route, fallback LLM, and error workflows. After the video, the challenge has you configure two of these on a real workflow. Finding the settings yourself and understanding when to use each one is where the learning happens.

What you'll practice:

• Configuring Retry on Fail in node settings
• Setting up a Split Error Route with success and error branches
• Watching Retry on Fail handle real, random API failures