Terminating Workflows with Stop and Error Nodes

Hello! Let's dive into the next piece of our error-handling puzzle.

In our last two lessons, we built a robust error management system. First, we created a global "catch-all" by setting up a dedicated error workflow. Then, we made our workflows more resilient to temporary glitches by implementing automatic retry logic. This handles unexpected, transient failures.

Today, we address a different class of problems: expected, logical failures. These are situations where the workflow receives data that is technically valid but fails a business rule or a validation check. Retrying is pointless here; for instance, if an email address is missing, trying again won't make it appear. For these cases, you need to deliberately stop the execution and raise a specific, meaningful error.

This is where the Stop and Error node comes in. For you as a software developer, this is the direct equivalent of throw new Error('Invalid input provided'). It’s how you programmatically halt a workflow path when your own rules are violated.

1. What is the Stop and Error Node?

The Stop and Error node is a simple yet powerful tool. When an execution path reaches this node, it does exactly what its name implies: it stops the current path and flags the entire workflow execution as failed. Its primary purpose is to allow you to define your own failure conditions within a workflow.

To get a quick overview, let's watch a short segment from the official n8n beginner's course.

As the video mentions, this node is your tool for handling edge cases where the data doesn't meet your expectations. Common scenarios include:

• Input Validation: A webhook arrives, but a required field like email or orderId is missing or empty.
• Business Logic Failure: An If node checks if an order total is greater than zero. If it's not, you want to stop and flag this as an error.
• Invalid Routing: A Switch node has paths for 'A', 'B', and 'C'. If the input is 'D', you can route the default output to a Stop and Error node to catch unexpected states.

2. Implementing Programmatic Failure

Using the Stop and Error node is almost always a two-step process:

1. Check a Condition: Use a logic node like If or Switch to check if your data is valid.
2. Throw the Error: If the data is invalid, route that execution path to the Stop and Error node.

Let's see this in practice. The next video segment demonstrates exactly this pattern, checking for a valid email and a valid event type from a webhook trigger.

The most critical part of this process is configuring the Error Message. A generic failure is hard to debug. A specific message like "Invalid Event: Event type was empty" tells you instantly what went wrong and where to look.

Test your understanding!

You have a workflow triggered by a webhook that receives product orders. The JSON body contains a quantity field. Your business rule states that quantity must be a positive integer (greater than 0).

Describe the nodes you would add to enforce this rule and what you would configure in the Stop and Error node.

Show answer

1. If Node: Add an If node after the trigger.
2. Condition: Set its condition to check if quantity is a number and is greater than 0. For example, a Number condition {{ $json.body.quantity }} with the operation Larger Than and value 0.
3. Stop and Error Node: Drag the false output of the If node to a new Stop and Error node.
4. Configuration: In the Stop and Error node, set the Error Message to something descriptive, like "Invalid Order: Quantity must be a positive number.".

3. Integrating with Your Error Handling Strategy

Here is where the concept becomes powerful, especially when combined with what we've already learned. When a Stop and Error node is triggered, it doesn't just fail the local execution. It also triggers your designated error workflow, passing along the custom message you defined.

This elevates the Stop and Error node from a simple terminator to a crucial part of your system's observability. You are no longer just stopping a workflow; you are sending a detailed, structured error report to your central error-handling process.

The following video demonstrates this beautifully. It shows how a custom error message from a Stop and Error node is caught by an Error Trigger in another workflow and then logged to a Google Sheet for tracking.

Node Behavior Settings

Finally, it's worth noting that the Stop and Error node has configurable behavior, though you will use the default setting most of the time. In the node's Settings tab, you can choose what happens on error:

• Stop Workflow (default): Halts the entire workflow execution and marks it as failed. This is the standard use case.
• Continue: Allows the workflow to continue despite the error. This is rare for this node but could be used if you simply want to log a non-critical issue without stopping execution.
• Continue (using error output): The node won't have a regular output but will provide an error output (the red connector) that you can connect to another node.

These advanced settings give you fine-grained control, but for most validation purposes, the default "Stop Workflow" is what you'll need.

Conclusion

You've now learned how to take control of your workflow's failure states. Instead of only reacting to unexpected crashes, you can now proactively define what constitutes an error in your specific business context.

Key Takeaways:

• The Stop and Error node is used to deliberately terminate a workflow path when a predefined condition or business rule is not met.
• It is typically used after logic nodes like If or Switch to perform input validation.
• Configuring a clear and specific error message is essential for quick debugging.
• The Stop and Error node fully integrates with your error workflow, passing your custom message to the Error Trigger for centralized processing and reporting.

We have now covered how to handle unexpected failures (error workflows), transient failures (retries), and logical failures (Stop and Error). The final step is to make sure a human is aware when a problem requires intervention. In our next lesson, we'll close the loop by learning how to set up notifications for workflow failures, ensuring that these well-defined errors are immediately brought to your attention.