Error Handling

Workflows fail. APIs go down, credentials expire, data is malformed. Error handling determines whether a failure is a minor hiccup or a broken process.

Types of failures

Failure	Cause	Example
Connection error	External API unreachable	Slack is down, Stripe returns 503
Auth error	Expired credentials	OAuth token expired, API key rotated
Data error	Invalid input data	Missing required field, wrong data type
Rate limit	Too many requests	API returns 429 Too Many Requests
Timeout	Request took too long	API didn't respond in 30 seconds
Logic error	Unexpected data shape	Field doesn't exist, null value where expected

Continue on error

The most basic error handling: enable Continue on error on a node so the workflow keeps running even if that node fails.

HTTP Request (continue on error: true) →
  If-Else ({{http.status}} === 200) →
    Success: Process response
    Failure: Log error → Send alert

Without continue-on-error, the workflow stops at the failed node. With it, execution continues, but downstream nodes may receive null/empty data.

Retry patterns

Simple retry

Repeat (3) →
  HTTP Request →
  If-Else (status === 200) →
    Success: Stop Loop
    Failure: Delay (2s) → continue
→ After loop: If-Else (final check) → handle failure

Exponential backoff

Repeat (5) →
  HTTP Request →
  If-Else (status === 200) →
    Success: Stop Loop
    Failure: Delay ({{2 ** iteration}} seconds) → continue

Wait 2s, 4s, 8s, 16s, 32s (progressively longer waits for each retry).

Rate limit handling

HTTP Request →
  If-Else (status === 429) →
    Rate limited: Delay (60s) → Jump To (HTTP Request)
    Other error: Log → Alert
    Success: Continue

Fallback patterns

Primary + fallback API

HTTP Request (primary API, continue on error) →
  If-Else (success?) →
    Yes: Use primary response
    No: HTTP Request (fallback API) →
      If-Else (fallback success?) →
        Yes: Use fallback response
        No: Send error alert → End

Graceful degradation

Person Enrichment (continue on error) →
  If-Else (enrichment succeeded?) →
    Yes: Create record with enriched data
    No: Create record with basic data (no enrichment) → Log warning

Error notification patterns

Immediate alert

[Failed node] → Send Email to Yourself (ERROR priority, "Workflow failed: {{error}}")

Aggregated errors

[Multiple nodes with continue on error] →
  Transformer (collect all errors) →
  If-Else (any errors?) →
    Yes: Send Slack (#errors, summary of all failures)
    No: Log success

Best practices

Always handle critical paths: payment processing, data writes, customer-facing actions
Use continue-on-error sparingly: only when you have a plan for the failure case
Set timeouts: don't wait forever for unresponsive APIs (default 30s is usually fine)
Log before alerting: capture error details in Log nodes for debugging
Monitor execution history: check for failed runs weekly
Test failure scenarios: intentionally break things to verify your error handling works

Warning

Continue-on-error without proper If-Else checking is dangerous: downstream nodes run with empty/null data, potentially corrupting your database or sending broken emails.

Tip

The Send Email to Yourself node with ERROR priority is your fastest debugging tool. Add it after any critical node's failure path.