Error Handling and Fallbacks
1. Error Handling and Fallbacks
Every workflow we've built so far has assumed that things go right. Data arrives, transforms, persists, and flows downstream.2. Well, that didn't go to plan...
But in production, things break. APIs go down, payloads arrive with missing fields, and calculations produce unexpected values. And when something breaks in a workflow that runs unattended on a schedule, nobody is watching. The workflow fails silently, and you only find out when a customer complains or a report is missing. That's why error handling is the single most important skill for production automation. In this video, we're going to learn three techniques for dealing with errors — validation checkpoints, global error catching, and per-node error routing.3. Stop and Error
The first technique is the Stop and Error node. Think of it as a circuit breaker we can place at critical points in the workflow. Before processing a user registration, it might check if the user has a user ID. Is the email address present? If the answer is no, we don't want the workflow to continue with bad data. We want it to stop immediately and tell us exactly what went wrong. The Stop and Error node does exactly that.4. Stop and Error
We configure it with a custom error message — something like "Registration rejected: missing user_id". When the workflow hits that node, it halts execution and surfaces that message in the execution log. It's a deliberate, controlled failure instead of an unpredictable one further downstream. We can chain multiple checkpoints: first verify the user_id exists, then verify the email is present. Each gate stops bad data before it's processed.5. Error Trigger Workflow
The second technique is the Error Trigger workflow — a separate workflow that fires automatically whenever another workflow fails. To create this error workflow, start a new workflow and add an Error Trigger node as the starting point. After the trigger, add an Edit Fields node to capture the error details — the workflow name, the node that failed, the error message, and a timestamp. This is our error monitor. Now switch to the workflow we want to monitor — open its Settings and set the Error Workflow to the error monitor we just created. From this point on, whenever the monitored workflow fails for any reason — a node throws an error, an API returns a 500, anything — the error monitor fires automatically with all the failure details. It's like having a watchdog for our automations.6. Error Output Connection
The final technique is the error output connection — the most surgical option. Instead of stopping the whole workflow or catching errors globally, this lets us handle errors on a specific node. Here's a workflow with an HTTP Request node that calls an external API. Sometimes that API is down, and the node fails — with a regular connection, the whole workflow stops. Open the node's settings and change "On Error" to "Continue Using Error Output." This creates a second path for errors, which we can chain to other nodes like regular connections. Now, when we execute the workflow, failed items get routed down the error path instead of halting everything, while successful items continue normally. Connect the error path to a logging or retry branch, and the workflow keeps running no matter what.7. Let's practice!
In the exercises, you'll practice all three techniques using order data: adding validation checkpoints that catch missing order IDs and invalid amounts, building an error monitoring workflow, and routing errors to separate paths.Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.