n8n Stop and Error Node

Invalid data flowing silently through your workflow causes downstream chaos. An order with a negative total slips through validation. A customer record missing required fields gets synced to your CRM. A malformed API response triggers cascading errors three nodes later. By the time you notice the problem, you are debugging symptoms instead of causes.

The Stop and Error node prevents this silent corruption. It lets you deliberately halt workflow execution and throw a custom error when data does not meet your requirements. Think of it as a circuit breaker for your automations. When something goes wrong, it stops everything immediately and tells you exactly what happened.

This guide covers everything you need to use the Stop and Error node effectively: custom error messages, structured error objects, validation patterns, webhook response strategies, and integration with error workflows.

The Silent Corruption Problem

Workflows do not always fail loudly. Sometimes they fail silently, processing bad data that causes problems downstream. A few examples:

• An API returns unexpected data, and your workflow writes garbage to your database
• Missing required fields pass validation because null values are not explicitly checked
• Edge cases slip through conditional logic and trigger unintended branches
• Malformed data propagates through multiple nodes before causing a visible failure

When these failures finally surface, tracing them back to the source takes hours. The Stop and Error node catches problems early, at the moment you know something is wrong, not three nodes later when symptoms appear.

What the Stop and Error Node Does

The Stop and Error node serves one purpose: force workflow execution to fail with an error you define. When it executes:

• The workflow immediately stops
• No downstream nodes run
• Your custom error message or object becomes the execution error
• The execution is marked as failed in the execution log
• Connected error workflows receive your error data and trigger their notifications

This controlled failure is exactly what you want when data validation fails or business rules are violated.

What You’ll Learn

• When to use the Stop and Error node versus Continue On Fail or Error Trigger
• The difference between Error Message and Error Object modes
• Step-by-step setup for your first Stop and Error node
• Validation patterns combining If nodes with Stop and Error
• Strategies for returning error responses to webhooks before stopping
• How Stop and Error integrates with Error Trigger workflows
• Real-world examples for order validation, API response checking, and data quality gates
• Common mistakes that cause confusion and exactly how to fix them

When to Use the Stop and Error Node

Before configuring the node, understand when it is the right choice versus other error handling approaches in n8n.

Approach	What It Does	Best For
Stop and Error	Immediately fails workflow with custom error	Validation failures, business rule violations, data quality gates
Continue On Fail	Lets workflow continue despite node errors	Expected failures, optional operations, graceful degradation
Error Trigger node	Catches workflow failures and runs error workflow	Production monitoring, team alerts, error logging
If node error checking	Routes data based on error conditions	Inline error handling without stopping workflow

Stop and Error is the Right Choice When:

• Invalid data should not be processed further under any circumstances
• Business rules require halting execution (negative order totals, missing required fields)
• You want explicit, descriptive error messages in execution logs
• The error should trigger notifications via your error workflow
• Data corruption risks outweigh the cost of workflow failure

Continue On Fail is Better When:

• Partial success is acceptable (some items fail, others succeed)
• The failing operation is optional or supplementary
• You want to handle errors inline without stopping everything
• Retrying the failed operation is the appropriate response

Rule of Thumb

Use Stop and Error when bad data flowing forward causes more damage than stopping the workflow. Use Continue On Fail when the workflow should proceed despite partial failures.

For comprehensive error workflow setup, see our Error Trigger node guide. The official n8n error handling documentation provides additional context on all available approaches.

Understanding the Two Error Types

The Stop and Error node offers two ways to define your error: Error Message and Error Object. Each serves different use cases.

Error Message Mode

Error Message mode throws a simple text error. This is the most common approach for straightforward validation failures.

Configuration:

1. Set Error Type to “Error Message”
2. Enter your custom error message in the Error Message field

Example error messages:

Order total cannot be negative
Customer email is required but was not provided
API response missing required 'data' field
Payment amount exceeds daily limit of $10,000

The message you provide becomes the execution.error.message field in error workflow data. Use descriptive messages that help diagnose the issue quickly.

Dynamic messages with expressions:

Include data from the workflow in your error message:

Order {{ $json.orderId }} has invalid total: {{ $json.total }}

Customer {{ $json.customerId }} missing required field: {{ $json.missingField }}

This context makes debugging much faster because the error message tells you exactly which record failed and why.

Error Object Mode

Error Object mode lets you throw structured JSON data as the error. Use this when you need to pass detailed information to your error workflow.

Configuration:

1. Set Error Type to “Error Object”
2. Enter your JSON object in the Error Object field

Example error object:

{
  "code": "VALIDATION_FAILED",
  "field": "order_total",
  "value": -50.00,
  "message": "Order total cannot be negative",
  "orderId": "{{ $json.orderId }}",
  "customerId": "{{ $json.customerId }}",
  "timestamp": "{{ $now.toISO() }}"
}

This structured data appears in your error workflow, where you can:

• Route errors differently based on error codes
• Include failed record identifiers for debugging
• Log detailed context to databases or monitoring systems
• Build rich Slack or email notifications with specific failure details

When to Use Each Mode

Scenario	Recommended Mode
Simple validation failures	Error Message
Need error codes for routing	Error Object
Want detailed context in error notifications	Error Object
Quick debugging is the priority	Error Message with expressions
Error workflow needs structured data for processing	Error Object
Multiple error types need different handling	Error Object with error codes

For most validation use cases, Error Message with dynamic expressions provides the right balance of simplicity and context. Upgrade to Error Object when your error workflow needs structured data for routing or logging.

Your First Stop and Error Node

Let’s build a practical example: stopping a workflow when an order total is invalid.

Step 1: Set Up the Validation Logic

First, add an If node to check your validation condition:

1. Add an If node after your data source
2. Configure the condition:
   • Value 1: {{ $json.order_total }}
   • Operator: less than
   • Value 2: 0
3. This checks if the order total is negative

Step 2: Add the Stop and Error Node

Connect the Stop and Error node to the If node’s true output (the path for invalid data):

1. Click + after the If node’s true output
2. Search for “Stop and Error”
3. Click to add it

Step 3: Configure the Error

1. Set Error Type to “Error Message”
2. Enter your message: Order {{ $json.orderId }} has invalid total: {{ $json.order_total }}
3. Save the node

Step 4: Connect the Valid Path

Connect the If node’s false output (valid data) to the rest of your workflow. Valid orders continue processing normally.

Step 5: Test the Configuration

Important constraint: The Stop and Error node can only be used as the last node in a workflow branch. You cannot connect any nodes after it. This is by design, as it terminates execution.

To test:

1. Pin test data with an invalid order (negative total)
2. Run the workflow
3. Verify the execution fails with your custom error message
4. Check the execution log shows your descriptive error

Understanding Testing Limitations

Error workflows connected to your main workflow only trigger during automated executions. If you click “Test Workflow” or “Execute Workflow” manually, the Stop and Error node will fail the workflow, but your error workflow will not run.

To test the full error flow:

1. Trigger the workflow automatically (via webhook, schedule, or other trigger)
2. Ensure the main workflow is active
3. Send data that triggers the Stop and Error node
4. Verify your error workflow receives the notification

This limitation exists because error workflows monitor production failures, not test runs. For more on testing error workflows, see our Error Trigger node guide.

Validation Patterns

The Stop and Error node becomes powerful when combined with validation logic. Here are proven patterns for common scenarios.

Pattern 1: Simple If + Stop and Error

The most straightforward pattern for single-condition validation:

Data Source → If (condition invalid?)
               → True: Stop and Error
               → False: Continue processing

Example: Required field validation

If node condition:

• Value 1: {{ $json.email }}
• Operator: does not exist (or is empty)
• Value 2: (none needed)

Stop and Error message:

Customer email is required but was not provided for record {{ $json.id }}

Pattern 2: Multiple Validation Checks

Chain multiple validations using a Switch node or cascading If nodes:

Data Source → If (check 1 invalid?)
               → True: Stop and Error ("Check 1 failed")
               → False: If (check 2 invalid?)
                          → True: Stop and Error ("Check 2 failed")
                          → False: Continue processing

Better approach using Code node:

For complex validation with many rules, use a Code node to consolidate logic:

const item = $json;
const errors = [];

// Validate required fields
if (!item.email) errors.push('Email is required');
if (!item.name) errors.push('Name is required');

// Validate data formats
if (item.email && !item.email.includes('@')) {
  errors.push('Email format is invalid');
}

// Validate business rules
if (item.order_total < 0) {
  errors.push('Order total cannot be negative');
}

if (item.order_total > 10000) {
  errors.push('Order total exceeds limit of $10,000');
}

// Return validation result
return [{
  json: {
    ...item,
    isValid: errors.length === 0,
    validationErrors: errors,
    errorMessage: errors.join('; ')
  }
}];

Then use an If node checking isValid and pass errorMessage to the Stop and Error node.

Test complex validation expressions with our expression validator tool.

Pattern 3: Data Quality Gates

Implement quality gates at critical points in your workflow:

API Response → If (response.success !== true)
                → True: Stop and Error ("API call failed: {{ $json.error }}")
                → False: Process response data

This ensures your workflow does not proceed with bad data from external services.

Pattern 4: Business Rule Enforcement

Stop execution when business rules are violated:

Example: Order limit enforcement

// Stop and Error message
Order {{ $json.orderId }} from customer {{ $json.customerId }}
exceeds daily limit. Amount: ${{ $json.total }}, Limit: ${{ $json.dailyLimit }}

These explicit failures create audit trails showing exactly when and why orders were rejected.

Webhook Error Response Strategies

A common challenge: you want to stop a workflow AND return an error response to the webhook caller. The Stop and Error node presents a problem here because it halts execution immediately, preventing any response from being sent.

The Problem

When you use Stop and Error after a Webhook node, the webhook caller receives no response. The connection hangs until timeout because the workflow stops before reaching any Respond to Webhook node.

Solution 1: Respond Before Stopping

Send the error response first, then stop:

Webhook → If (validation fails?)
           → True: Respond to Webhook (400 error) → Stop and Error
           → False: Process → Respond to Webhook (200 success)

Respond to Webhook configuration:

1. Set Respond With to “JSON”
2. Set the response body:

{
  "success": false,
  "error": "Validation failed: {{ $json.validationError }}"
}

3. Set Response Code to 400 (or appropriate error code)

The webhook caller receives the error response immediately. Then the Stop and Error node runs, logging the failure and triggering your error workflow.

Solution 2: Continue On Fail with Error Output

For more complex scenarios, use Continue On Fail with error output routing:

1. On the node that might fail, enable Continue On Fail with Error Output
2. The node creates two outputs: success and error
3. Route the error output to Respond to Webhook (with error response)
4. After responding, optionally add Stop and Error to log the failure

This approach works well when the failure might occur in a middle node (like an HTTP Request) rather than during explicit validation.

Solution 3: Centralized Error Response Handler

For workflows with multiple potential failure points, create a centralized error handler:

Any validation failure → Set Error Details → Respond to Webhook (error) → Stop and Error

Use a Set node to standardize error response format before responding:

{
  "success": false,
  "error": {
    "code": "{{ $json.errorCode }}",
    "message": "{{ $json.errorMessage }}",
    "field": "{{ $json.errorField }}"
  }
}

For HTTP status code reference, see the MDN HTTP status codes documentation.

Integration with Error Workflows

When the Stop and Error node executes, it triggers the error workflow connected to your main workflow. Understanding this integration helps you build effective error handling.

How It Works

1. Stop and Error executes with your custom error message or object
2. The workflow execution is marked as failed
3. n8n checks if an error workflow is configured in workflow settings
4. If configured, the Error Trigger node in that workflow receives the error data
5. Your error workflow runs, sending notifications or logging the failure

Error Data Structure

Your error workflow receives data in this structure:

{
  "execution": {
    "id": "12345",
    "url": "https://your-n8n.com/execution/12345",
    "error": {
      "message": "Your custom error message here",
      "stack": "Error: Your custom error message here\n    at..."
    },
    "lastNodeExecuted": "Stop and Error",
    "mode": "trigger"
  },
  "workflow": {
    "id": "67",
    "name": "Order Processing Workflow"
  }
}

Your custom error message appears in execution.error.message. Access it in error workflow nodes with:

{{ $json.execution.error.message }}

Using Error Object Data

If you used Error Object mode, your structured data is serialized into the error message. To use structured error data effectively in notifications, include key information in the message itself, or parse the JSON in a Code node in your error workflow.

Recommended approach: Include identifiers in Error Message mode:

[ORDER_VALIDATION_FAILED] Order {{ $json.orderId }} rejected: total is negative ({{ $json.total }})

Then parse the bracketed code in your error workflow to route different error types to different notification channels.

Connecting Your Error Workflow

To connect an error workflow to your main workflow:

1. Open your main workflow in the editor
2. Click Settings (gear icon, top right)
3. Find Error Workflow in the settings panel
4. Select your error handler workflow from the dropdown
5. Save the workflow

The dropdown shows all workflows containing an Error Trigger node. For detailed setup instructions, see our Error Trigger node guide.

Alternative Approaches

The Stop and Error node is not always the right choice. Here are alternative approaches for different scenarios.

Returning an Empty Array to Stop Gracefully

If you want to stop workflow execution without triggering error handling, return an empty array from a Code node:

// Check condition
if ($json.shouldStop) {
  return []; // Empty array stops execution without error
}

// Continue normally
return [$input.item];

Important: The Code node must be set to Run Once for All Items mode. If set to run per item, returning an empty array causes a type error.

When to use this:

• Conditional termination that is not an error condition
• Filtering out all items based on criteria
• Early exit when no work needs to be done

Limitations:

• No error is logged
• Error workflow does not trigger
• No visibility into why execution stopped (unless you add logging)

Continue On Fail with Manual Routing

For partial failure scenarios where some items should succeed:

1. Enable Continue On Fail with Error Output on potentially failing nodes
2. Route successful items to continue processing
3. Route failed items to error logging or alternative handling
4. Optionally use Stop and Error only if all items fail

This pattern is useful for batch processing where you want maximum throughput despite some failures.

When Each Approach Fits

Scenario	Best Approach
Validation failure that should never proceed	Stop and Error
Expected “no data” condition	Return empty array
Some items fail, others should succeed	Continue On Fail
Non-critical failure, workflow should continue	Continue On Fail
Critical failure needing team notification	Stop and Error + Error Workflow
Testing/debugging early exit	Return empty array

Real-World Examples

Example 1: Order Validation Gateway

Scenario: Validate orders before processing. Reject orders with invalid data.

Webhook (order) → Code (validate) → If (isValid?)
                                      → True: Process order
                                      → False: Respond (400) → Stop and Error

Validation Code node:

const order = $json;
const errors = [];

// Required fields
if (!order.customerId) errors.push('Customer ID required');
if (!order.items || order.items.length === 0) errors.push('Order must have items');

// Business rules
if (order.total <= 0) errors.push('Order total must be positive');
if (order.total > 50000) errors.push('Order exceeds $50,000 limit');

// Data quality
if (order.email && !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(order.email)) {
  errors.push('Invalid email format');
}

return [{
  json: {
    ...order,
    isValid: errors.length === 0,
    validationErrors: errors,
    errorMessage: errors.length > 0
      ? `Order ${order.orderId} validation failed: ${errors.join(', ')}`
      : null
  }
}];

Stop and Error message:

{{ $json.errorMessage }}

Example 2: API Response Validation

Scenario: Verify API responses contain expected data before processing.

HTTP Request → If (response.data exists?)
                → True: Process data
                → False: Stop and Error

If node condition:

• Value 1: {{ $json.data }}
• Operator: does not exist

Stop and Error message:

API response missing required 'data' field. Status: {{ $json.statusCode }}, Body: {{ JSON.stringify($json) }}

For HTTP Request configuration and error handling, see our HTTP Request node guide.

Example 3: Data Quality Gate

Scenario: Prevent bad data from reaching your database.

Transform Data → Code (quality check) → If (quality score < threshold?)
                                          → True: Stop and Error
                                          → False: Database Insert

Quality check Code node:

const record = $json;
let qualityScore = 100;
const issues = [];

// Check for missing critical fields
if (!record.primaryKey) {
  qualityScore -= 50;
  issues.push('Missing primary key');
}

// Check for suspicious values
if (record.amount < 0) {
  qualityScore -= 30;
  issues.push('Negative amount');
}

// Check for data consistency
if (record.startDate > record.endDate) {
  qualityScore -= 25;
  issues.push('Start date after end date');
}

return [{
  json: {
    ...record,
    qualityScore,
    qualityIssues: issues,
    passesQualityGate: qualityScore >= 70
  }
}];

Example 4: Circuit Breaker Pattern

Scenario: Stop processing if an external service has failed multiple times.

Get Failure Count → If (failures > threshold?)
                      → True: Stop and Error ("Circuit breaker open")
                      → False: Call External Service → Update failure count

Stop and Error message:

Circuit breaker open: {{ $json.serviceName }} has failed {{ $json.failureCount }} times in the last {{ $json.windowMinutes }} minutes. Manual intervention required.

This pattern prevents cascading failures when dependencies are unstable. For more patterns, see our workflow best practices guide.

Common Mistakes and How to Fix Them

Mistake 1: Using Stop and Error as a Non-Terminal Node

Symptom: Error when trying to connect nodes after Stop and Error.

Why it fails: The Stop and Error node can only be the last node in a workflow branch. n8n prevents connections after it because execution terminates there.

Fix: Restructure your workflow so Stop and Error is always at the end of its branch. If you need to perform actions before stopping, add them before the Stop and Error node.

Mistake 2: Expecting Error Workflow to Run on Manual Tests

Symptom: You click “Test Workflow,” the Stop and Error node triggers, but your error workflow does not run.

Why it fails: Error workflows only trigger during automated (production) executions. Manual test runs do not trigger connected error workflows.

Fix: To test the full error flow:

1. Activate your main workflow
2. Trigger it automatically (webhook, schedule, etc.)
3. Send data that triggers the Stop and Error node
4. Verify your error workflow runs

This is intentional behavior to separate testing from production monitoring.

Mistake 3: Not Connecting Error Workflow in Settings

Symptom: Stop and Error runs, workflow fails, but no notification arrives.

Why it fails: You must explicitly connect an error workflow in the main workflow’s settings. Creating an error workflow with an Error Trigger node is not enough.

Fix:

1. Open your main workflow
2. Click Settings (gear icon)
3. Select your error workflow in the “Error Workflow” dropdown
4. Save

Mistake 4: Webhook Response Never Sent

Symptom: Webhook callers timeout waiting for response when Stop and Error triggers.

Why it fails: Stop and Error halts execution immediately. If no Respond to Webhook node ran before it, no response is sent.

Fix: Add a Respond to Webhook node before the Stop and Error node on error paths. See the “Webhook Error Response Strategies” section above.

Mistake 5: Generic Error Messages

Symptom: Error logs show “Validation failed” without context, making debugging difficult.

Why it fails: Static error messages without data context require investigating the execution to understand what failed.

Fix: Include dynamic data in error messages:

❌ "Validation failed"
✅ "Order {{ $json.orderId }} validation failed: {{ $json.errorDetails }}"

Use our workflow debugger tool to identify issues in complex workflows.

Pro Tips and Best Practices

1. Write Descriptive Error Messages

Your future self (and teammates) will thank you:

❌ "Error"
❌ "Invalid data"
✅ "Order ORD-12345 rejected: total ($-50.00) cannot be negative"
✅ "Customer CUS-789 missing required email field for order ORD-456"

Include: what failed, which record, why it failed, and relevant values.

2. Include Context in Error Objects

When using Error Object mode, include identifiers for quick debugging:

{
  "errorType": "VALIDATION",
  "errorCode": "INVALID_AMOUNT",
  "recordId": "{{ $json.id }}",
  "recordType": "order",
  "failedValue": "{{ $json.amount }}",
  "constraint": "must be positive",
  "workflow": "Order Processing",
  "timestamp": "{{ $now.toISO() }}"
}

This structured data helps error workflows route and log failures effectively.

3. Position Validation Early

Validate data as soon as it enters your workflow:

Webhook → Validate → Process → Save

Not:

Webhook → Process → Process → Save → Validate (too late!)

Catching bad data early prevents wasted processing and makes errors easier to trace.

4. Log Before Stopping

If you need detailed logs beyond what error workflows capture:

If (invalid?) → Set (error details) → Google Sheets/Airtable (log) → Stop and Error

This creates a searchable history of validation failures for trend analysis.

5. Use Consistent Error Codes

Establish error code conventions for your organization:

[ORDER_001] Missing required field
[ORDER_002] Invalid amount
[API_001] External service unavailable
[DATA_001] Quality check failed

Consistent codes make error routing and reporting much easier.

6. Monitor Error Patterns

Track Stop and Error triggers over time:

• Which validations fail most often?
• Are certain data sources producing more errors?
• Do failures cluster around specific times?

This data helps improve upstream systems and reduce failure rates.

For strategic guidance on workflow reliability, explore our consulting services.

When to Get Help

The Stop and Error node is straightforward for basic validation. Some scenarios benefit from expert assistance:

• Complex validation logic with many interdependent rules
• High-stakes workflows where validation failures have significant business impact
• Multi-system error handling requiring coordinated responses across services
• Compliance requirements mandating specific error logging and audit trails
• Performance optimization for high-volume workflows with many validation points

Our workflow development services include production-ready error handling patterns and validation frameworks.

Frequently Asked Questions

Can I use the Stop and Error node in the middle of a workflow, not just at the end?

No. The Stop and Error node must be the last node in its workflow branch. You cannot connect any nodes after it because it immediately terminates execution. This is a fundamental design constraint of the node.

If you need to perform actions before stopping (like logging or sending a response), add those nodes before the Stop and Error node on the same branch. Structure your workflow so the Stop and Error node is always a terminal point. For conditional stopping, use an If node to branch into a path ending with Stop and Error, while the other path continues normally.

How do I return an error response to a webhook caller before the workflow stops?

Add a Respond to Webhook node before the Stop and Error node on your error path. Configure it to return an appropriate HTTP status code (like 400 or 422) and include error details in the response body.

For example:

Webhook → If (validation fails?)
           → True: Respond to Webhook (400, error JSON) → Stop and Error
           → False: Process → Respond to Webhook (200, success)

The webhook caller receives the error response immediately. Then Stop and Error runs, which logs the failure and triggers your error workflow for team notification. See the “Webhook Error Response Strategies” section for detailed implementation patterns.

Why doesn’t my error workflow run when I click “Test Workflow” on a workflow with Stop and Error?

Error workflows only trigger during automated workflow executions, not manual tests. This is intentional behavior in n8n. When you manually run a workflow (clicking “Test Workflow” or “Execute Workflow”), the Stop and Error node will fail the execution, but your connected error workflow will not run.

To test the complete error flow:

1. Activate your main workflow
2. Trigger it automatically via webhook, schedule, or other trigger
3. Send data that causes the Stop and Error node to execute
4. Verify your error workflow receives the notification

This separation exists because error workflows are designed for production monitoring, not test-time debugging. During development, you can verify Stop and Error works by checking that the execution fails with your custom message.

What’s the difference between the Stop and Error node and the Continue On Fail setting?

These serve different purposes. Stop and Error deliberately fails the workflow when you decide conditions warrant failure. It is active and intentional. You add it to specific branches where invalid data should halt everything.

Continue On Fail is a passive setting on nodes that might fail unexpectedly (HTTP requests, database operations). It lets the workflow continue despite that node’s failure, routing failed items to an error output for handling.

Use Stop and Error when: bad data should never proceed further (validation failures, business rule violations).

Use Continue On Fail when: you want the workflow to continue despite some failures (optional enrichment, partial batch processing, graceful degradation).

Many production workflows use both: Continue On Fail on nodes with expected transient failures, and Stop and Error for explicit validation that catches anything that slips through.

How do I include custom data in my error workflow notifications when using Stop and Error?

Include the data directly in your Stop and Error message using expressions:

Order {{ $json.orderId }} from customer {{ $json.customerId }} failed validation: {{ $json.errorDetails }}

This message appears in your error workflow as $json.execution.error.message, which you can include in Slack notifications, emails, or database logs.

For more structured data, use Error Object mode and include a JSON object with all relevant fields. However, note that accessing individual fields from an Error Object requires parsing in your error workflow. For most cases, a well-formatted Error Message with expressions provides the best balance of simplicity and detail.

To build rich error notifications, your error workflow can combine the error message with the workflow name ($json.workflow.name) and execution URL ($json.execution.url) for complete context. See our Error Trigger node guide for notification templates.