Resources · n8n integration

n8n Stop and Error nodeConfigure Stop and Error in n8n.

Some workflows are better off failing loudly than finishing quietly. The n8n Stop and Error node ends the current run where you drop it and throws the message or the JSON object you wrote. One parameter, 2 error types, version 1 in the catalog. Useful for any branch that should never reach the next node.

Verified Trustpilot reviews · AI, automation & growth agency

Why automate

What does the n8n Stop and Error node actually do?

Stop and Error makes the current execution fail, right at the spot where you placed it. Rather than letting a run finish on data you already know is wrong, the node throws an error you wrote yourself, either a readable message or a JSON object, and the execution is marked as failed. n8n ships it as a core node, so it is already sitting in the panel with nothing to install.

The first scenario is the guard. A run starts on a Webhook, which is a URL an outside service calls to hand n8n a payload, and the payload sometimes arrives without the identifier the rest of the workflow depends on. An If node checks the field, the false branch goes straight into Stop and Error, and the run stops there instead of writing a half empty row three nodes later.

The second scenario is reporting. With the errorObject option you throw a structured object rather than a sentence, so the workflow that reacts to the failure can read the properties one by one. n8n documents this pairing: the Error Trigger node starts an error workflow, and the custom error information you threw travels with it. A code and a description are enough to route the alert to the right person.

The third scenario sits behind an API call. An HTTP Request node returns a body that is technically a success but useless for what comes next, an empty list where a record was expected. Stop and Error turns that silent case into a visible failed execution, which is much easier to spot than a run that ended green with nothing written.

Prefer a different node when the branch still has a valid continuation. Switch handles more than two outcomes and keeps them all running. Merge brings two paths back together when both are legitimate. Stop and Error belongs only where there is nothing sensible left to do with the item in front of you.

The limits are short to list. The node exposes a single parameter, so there is nothing to tune beyond the error you throw. It runs on every incoming item, and it never opens a workflow by itself: a Schedule Trigger, a Webhook or the trigger of a tool has to come first. If you are still weighing the platform before wiring failure handling into it, the n8n review covers the ground around this node.

Parameters

Which parameter does Stop and Error expose?

The Stop and Error node has one parameter. For each one: the node as you configure it in n8n, what the parameter changes, and our field notes.

01

Error Type

errorType

What you see in n8n

Notes & use cases

Error Type selects the type of error to throw, and the choice changes the field shown underneath.

Key parameters

  • Error Type: two options, errorMessage (Error Message) and errorObject (Error Object).
  • Error Message: required with the first option, a string in the shape of the placeholder An error occurred!, often assembled from the incoming item with {{ $json.status }}.
  • Error Object: required with the second option, a JSON object containing the error properties, such as { "code": "404", "description": "The resource could not be fetched" }.
Use cases
throw a message when a human reads the failure in the execution list, an object when another workflow sorts failures by code.
Need help

Need help automating Stop and Error with n8n?

A person reads every message.

FAQ

Stop and Error in n8n, answered

01Is the Stop and Error node included in n8n Cloud and self-hosted?
Yes. Stop and Error is a core node shipped with n8n, so there is no install step and no extra cost on the n8n side. It behaves the same on n8n Cloud, the hosted offer run by n8n, and on a self-hosted instance set up with Docker or npm under the Community Edition and its Sustainable Use license. A workflow that fails on purpose in one place fails the same way in the other, which matters when a project starts on Cloud and moves onto your own server later. The catalog lists the node at version 1, and none of it sits behind a paid tier.
02What do you need to set up before using Stop and Error?
Nothing on the account side. The node has no credential, meaning no stored set of connection details, and no Authentication selector, so there is no key to paste and no access to approve before the first run. What it does need is a trigger in front of it, because it never opens a workflow on its own: a Schedule Trigger, a Webhook or the trigger of a tool starts the execution and Stop and Error sits somewhere downstream. Fill the field that matches the error type you picked, since a required field left empty blocks the node.
03What are the limits of the n8n Stop and Error node?
It throws, and that is the whole job. The node carries one parameter with 2 options, so there is nothing else to configure once the message or the object is written. It runs on every incoming item, so a batch arriving at the node fails on the item it is processing. Reading what went wrong is a separate job: the Error Trigger node starts the error workflow that receives the information you threw. The catalog stops at version 1, so an older workflow shows the same short panel rather than a reduced one.
04When should you use Stop and Error instead of an If node?
If routes, Stop and Error ends. An If node sends items down a true branch or a false branch and both keep running, with nothing marked as failed. Reach for Stop and Error when one of those branches has no valid continuation, for instance a record that showed up without the identifier every later node needs. In practice the two work as a pair: If asks the question, Stop and Error answers it for the bad half, and Switch does the same job when there are more than two outcomes. Keep it out of branches where an empty result is a normal, acceptable ending.
05n8n or Make for handling failures like this?
Both draw the same kind of visual logic, so the canvas rarely decides it. n8n runs on your own server with Docker or npm, or on n8n Cloud; Make is hosted only, with no self-hosting option, and it bills per operation. If the data moving through the failing branch has to stay on infrastructure you control, self-hosting settles the question. If the volume is small and running a server holds no appeal, the hosted side of either tool does the job. On cost, weigh the operations a run consumes in Make against what a server or a Cloud plan costs you.
Hack'celeration Lab

Get our weekly integration tips.

No spam. Unsubscribe anytime.