Reference · Tools
Stop and Error
Throw an error in the workflow to stop execution with a custom error message or object.
Stop and Error throws an error on purpose, ending the run with a message or error object you define. It needs no credentials. A typical build is validating a precondition and failing loudly when it is not met, rather than letting bad data flow onward silently.
- Node type
- Action
- Parameters
- 4
- Outputs
- Output, Error
- Credentials
- None required
Stop and Error
Throw an error to stop workflow execution
Overview
The Stop and Error tool intentionally throws an error to halt workflow execution. It supports two modes: a simple error message string, or a JSON error object with structured fields (message, description, code, type). Use this when a workflow should fail with a specific error under certain conditions.
Category: Core Nodes
Tool Name: stop_and_error
Version: 1
Appearance: Icon: lucide-OctagonX | Color: #ff0000
Node Type
Action — processes input items and produces output
Input / Output
| Direction | Port(s) |
|---|---|
| Input | Input |
| Output | Output, Error |
Credentials
This tool does not require any credentials.
Parameters
| Parameter | Type | Required | Default | Description |
|---|---|---|---|---|
| Error Type | options | No | errorMessage | Type of error to throw. |
Options: errorMessage, errorObject | ||||
| Error Message | string | Yes | — | The error message to throw. (shown when Error Type is errorMessage) |
| Error Object | json | Yes | — | Object containing error properties. Supports fields: message, description, error, code, type. (shown when Error Type is errorObject) |
| Max Concurrency | number | No | 10 | Maximum number of items to process concurrently. |
Output Data
This node always fails the items it receives — that is its whole purpose. What reaches the rest of the workflow depends on the node’s error-handling mode:
- stop — the first item throws and the workflow run halts. Nothing is emitted.
- continue (the default) — each input item is turned into an error item and leaves on
Output, carrying an_errorobject alongside the original item JSON. Downstream nodes will see them, so check for_errorbefore treating that branch as normal traffic. - errorPort — the same error items are routed to the
Erroroutput instead, leavingOutputempty.
The message on the error is resolved once for the whole node run:
- With Error Type
errorMessage, the message is the Error Message text, orWorkflow stopped with errorwhen it is empty. - With Error Type
errorObject, the message is the object’smessage, falling back todescription, thenerror, and finally to the whole object rendered as JSON.descriptionis carried through when present, and the full object you supplied is attached to the error as its metadata. Text that is not valid JSON produces the messageInvalid error JSON: …rather than silently succeeding.
Usage Examples
- Stop workflow when invalid data is detected
- Throw custom error with structured JSON error object
- Halt execution with descriptive error message
Example Configuration
Fail with a plain message:
{
"type": "stop_and_error",
"parameters": {
"errorType": "errorMessage",
"errorMessage": "Validation failed: Required field is missing"
}
}
Fail with a structured error object:
{
"type": "stop_and_error",
"parameters": {
"errorType": "errorObject",
"errorObject": {
"message": "Authentication failed",
"description": "The provided API key is invalid or expired",
"error": "INVALID_API_KEY",
"code": 401,
"type": "AuthenticationError"
}
}
}
Fail a validation branch, limiting how many items are processed at once:
{
"type": "stop_and_error",
"parameters": {
"errorType": "errorMessage",
"errorMessage": "Invalid input: email address format is incorrect",
"maxConcurrency": 5
}
}
Return an API-style error:
{
"type": "stop_and_error",
"parameters": {
"errorType": "errorObject",
"errorObject": {
"message": "Resource not found",
"description": "The requested user ID does not exist in the database",
"error": "USER_NOT_FOUND",
"code": 404,
"type": "NotFoundError"
}
}
}
Raise a business-rule failure:
{
"type": "stop_and_error",
"parameters": {
"errorType": "errorObject",
"errorObject": {
"message": "Insufficient funds",
"description": "Account balance is too low to complete this transaction",
"error": "INSUFFICIENT_BALANCE",
"code": 422,
"type": "BusinessRuleError"
},
"maxConcurrency": 1
}
}
Error Handling
| Mode | Behavior |
|---|---|
| stop | Halts workflow on first error |
| continue | Skips failed items, passes successful ones through |
| errorPort | Routes failed items to Error output port |
Tips
Intentionally throws an error to stop workflow execution with a custom message or error object.
Behavior notes
- Put it behind a condition. This node fails everything that reaches it, so gate it with an If or Switch node — wire only the branch that represents the failure case into it.
- Set the node’s error handling to
stopif you want the run to actually halt. On the defaultcontinuesetting the error becomes an item and the workflow keeps going. - The error text is fixed, not per item. Error Message and Error Object are read once for the node and used verbatim for every item, so write a message that makes sense on its own rather than one that depends on a particular record. To include values from the data, build the message in an upstream node and branch on it.
Frequently asked questions
Where should I put it?
Behind a condition. The node fails everything that reaches it, so gate it with an If or Switch and wire only the failure branch into it.
Why did the run continue after it errored?
Because the node's error handling is on the default `continue` setting, which turns the error into an item rather than halting. Set it to `stop` if you want the run to actually halt.
What can the error contain?
A custom message or a full error object, so downstream tooling and logs can carry the context of why the run was stopped.
Does it need credentials?
No.
Build with the Stop and Error node
Drop it into a workflow, wire it to an agent, or call it on a schedule.
Open BusyBotLast updated . Spotted something wrong? Tell us.