Go to Studio

Fail

Stop workflow execution with a custom error

What does this node do?

The Fail node stops workflow execution and displays a custom error message. Use it to validate data, enforce business rules, or gracefully handle error conditions.

Common uses:

  • Validate required data
  • Enforce business rules
  • Handle expected errors
  • Provide clear error messages

Quick setup

Add a Conditional node

Check for the error condition

Write a clear error message

Explain what went wrong

Configuration

Required fields

error_message string required

The error message to display when the workflow fails.

Tips for good error messages:

  • Explain what went wrong
  • Include relevant data values
  • Suggest how to fix it

Examples:

"No URL provided. Please enter a valid URL to scrape."

"Invalid API response: {{status}}. Check API credentials."

"Content too short ({{wordCount}} words). Minimum is 500 words."

Output

When triggered, the workflow stops and returns:

{
  "status": "failed",
  "error": {
    "message": "No URL provided. Please enter a valid URL.",
    "code": "VALIDATION_ERROR",
    "node": "Fail_0",
    "timestamp": "2024-01-15T10:30:00Z"
  }
}

Examples

Data validation

Validate required input:

graph LR
    A[Input] --> B{URL provided?}
    B -->|Yes| C[Continue]
    B -->|No| D[Fail: No URL]

Error message:

"URL is required but was not provided. 
Please enter a valid URL to continue."

Business rule enforcement

Enforce minimum content length:

graph LR
    A[Content] --> B{Word count >= 500?}
    B -->|Yes| C[Publish]
    B -->|No| D[Fail: Too short]

Error message:

"Content is too short ({{wordCount}} words). 
Minimum required: 500 words. 
Please expand the content before publishing."

API error handling

Handle API failures:

graph LR
    A[API Call] --> B{Status 200?}
    B -->|Yes| C[Process]
    B -->|No| D[Fail: API Error]

Error message:

"API request failed with status {{HTTP_0.status}}.
Response: {{HTTP_0.body.error}}
Please check your API credentials and try again."

Rate limit protection

Stop before hitting limits:

graph LR
    A[Check Usage] --> B{Under limit?}
    B -->|Yes| C[Continue]
    B -->|No| D[Fail: Limit reached]

Error message:

"API rate limit reached ({{usage}}/{{limit}} calls).
Please wait {{resetTime}} before running again."

Best practices

Write helpful error messages

Include context to help users fix the issue:

❌ "Error occurred"

✅ "Failed to scrape URL: {{url}}. 
   The page returned a 403 Forbidden error. 
   This usually means the site blocks automated requests.
   Try a different URL or add a delay between requests."

Include relevant values

Show the actual data that caused the failure:

"Score validation failed.
 Received: {{score}}
 Expected: >= 0 and <= 100
 Please check the scoring logic."

Fail early

Validate inputs at the beginning:

graph LR
    A[Start] --> B{Input valid?}
    B -->|No| C[Fail early]
    B -->|Yes| D[Do expensive work]

Don’t process data only to fail at the end.

Use consistent error codes

Create a standard set of error codes:

CodeMeaning
VALIDATION_ERRORInput data is invalid
API_ERRORExternal API failed
AUTH_ERRORAuthentication failed
RATE_LIMITRate limit exceeded
DATA_MISSINGRequired data not found

Consider alternatives

Before using Fail, consider:

  • Conditional: Route to a different path instead
  • Default values: Use fallbacks for missing data
  • Retry logic: Try again for transient failures

Common patterns

Validation at start

graph LR
    A[Input] --> B{Valid?}
    B -->|No| C[Fail]
    B -->|Yes| D[Process]
    D --> E[Output]

Multiple validation checks

graph LR
    A[Input] --> B{Has URL?}
    B -->|No| F[Fail: Missing URL]
    B -->|Yes| C{Valid format?}
    C -->|No| G[Fail: Invalid format]
    C -->|Yes| D{Reachable?}
    D -->|No| H[Fail: Unreachable]
    D -->|Yes| E[Process]

Graceful degradation

graph LR
    A[Try Primary] --> B{Success?}
    B -->|Yes| C[Use Primary]
    B -->|No| D[Try Fallback]
    D --> E{Success?}
    E -->|Yes| F[Use Fallback]
    E -->|No| G[Fail: All options exhausted]

When NOT to use Fail

Don’t fail for expected cases

If “no data” is a valid outcome:

❌ Fail: "No results found"
✅ Conditional → Handle empty results gracefully

Don’t fail in loops

One bad item shouldn’t stop everything:

❌ Loop → Item fails → Entire workflow stops
✅ Loop → Item fails → Log error → Continue to next

Don’t fail without context

Always explain what went wrong:

❌ Fail: "Error"
✅ Fail: "Database connection failed after 3 retries. 
         Check database credentials in Settings → Integrations."