NodeBridge #7: My Three-Tier Advanced Error Handling System

Issue 7 • January 27, 2026

Your workflow fails at 2 AM. You get an alert. You're half asleep, fumbling with your phone, trying to figure out what broke and whether it can wait until morning.

It can't. 847 orders are stuck. Customers are waiting. You log in, find the error, fix it manually, restart the workflow, and hope nothing else breaks while you go back to sleep.

The next night, same thing. Different error, same outcome: you're awake, fixing things manually, wondering why you automated anything in the first place.

This is what happens when your error handling strategy is "send me an alert." Alerts are necessary but not sufficient. Production workflows need to handle errors automatically: retry when appropriate, fail gracefully when not, and only wake you up when human judgment is absolutely necessary.

Today I'm giving you the three-tier error handling system that handles 90% of failures without human intervention.

Why Basic Error Handling Fails

Most automation builders do this:

[Trigger] → [Action] → [Done]

When they get burned, they upgrade to:

[Trigger] → [Action] → [On Error: Send Slack Alert]

Better. But now every failure, whether it's a temporary network hiccup or a critical authentication issue, gets the same treatment: wake up the human.

The problem: not all errors are equal.

• Temporary failures (network timeout, rate limit, server overload) will succeed if you retry in 30 seconds
• Data failures (missing field, invalid format, business rule violation) will never succeed without human review
• Critical failures (auth expired, API key revoked, service discontinued) need immediate attention and shouldn't process more data

Treating them the same wastes your time and lets recoverable failures become permanent.

The Three-Tier Error Handling System

Tier 1: Automatic Retry (Temporary Failures)

When to use: Network timeouts, rate limit errors, 5xx server errors, connection resets

Why it works: These failures are temporary. The API is overloaded, your network hiccuped, or you hit a rate limit. Wait a few seconds and try again; it'll probably work.

Implementation:

• Retry up to 3 times
• Use exponential backoff: 30s, 60s, 120s
• Log each retry attempt
• If all retries fail, escalate to Tier 2

n8n Configuration:

HTTP Request Node Settings:
- Retry on Fail: Enabled
- Max Tries: 3
- Wait Between Tries: 30000ms
- Backoff: Exponential

What this catches:

• Stripe API returning 429 (rate limit)
• Google Sheets timing out during heavy load
• Webhook destination temporarily unavailable
• Database connection dropped

Tier 2: Log and Alert (Data Failures)

When to use: Validation errors, missing required fields, invalid data formats, business logic violations

Why different from Tier 1: Retrying won't help. The data is wrong. A human needs to review, fix the data, and decide whether to reprocess.

Implementation:

• Don't retry (data won't fix itself)
• Log the complete record to external storage
• Send alert with enough context to investigate
• Continue processing other records (don't let one bad record stop everything)
• Create a "failed records" queue for manual review

What to log:

• Timestamp
• Workflow name and execution ID
• Error message
• Full input data (so you can replay later)
• Which step failed

n8n Pattern:

[Process Item]
    |
[On Error] → [Set: Extract Error Details]
    |
    → [Google Sheets: Log Failed Record]
    |
    → [Slack: Send Alert with Link to Logs]
    |
    → [Continue to Next Item]

What this catches:

• Customer record missing email address
• Order total is negative (business rule violation)
• Date format doesn't match expected pattern
• Referenced record doesn't exist in destination system

Tier 3: Fail Fast (Critical Failures)

When to use: Authentication failures, permission errors, API key revoked, critical service unavailable

Why fail fast: If your auth is broken, every subsequent API call will fail. Processing more records wastes time and potentially corrupts data. Stop immediately.

Implementation:

• Stop workflow immediately
• Send urgent alert (consider PagerDuty for truly critical workflows)
• Don't process any more records
• Require manual intervention before resuming
• Log what was processed vs. what wasn't

n8n Pattern:

[API Call]
    |
[Check: Is Error 401 or 403?]
    |
[Yes] → [Stop Workflow Node]
    |
    → [Urgent Alert: Auth Failed, Manual Fix Required]

What this catches:

• OAuth token expired
• API key was rotated but workflow wasn't updated
• Service account permissions were changed
• Third-party API discontinued endpoint

Implementing the Three-Tier System

Here's how to add this to an existing workflow:

Step 1: Identify Error Types

For each external API call in your workflow, list the possible errors:

• What HTTP status codes can it return?
• What does the error response body look like?
• Which errors are temporary vs. permanent?

Step 2: Add Error Classification

After each risky operation, add a Switch node that checks the error type:

[HTTP Request]
    |
[On Error] → [Switch: Check Error Type]
    |
    ├─ 429, 5xx, timeout → [Tier 1: Retry]
    ├─ 400, validation error → [Tier 2: Log and Alert]
    └─ 401, 403 → [Tier 3: Fail Fast]

Step 3: Build Your Recovery Queue

Create a separate workflow that:

1. Reads failed records from your log (Google Sheets, database)

2. Presents them for review

3. Allows you to fix data and reprocess

4. Marks records as resolved

This turns "847 failures to investigate" into "review 12 data issues, click reprocess."

Circuit Breakers: Preventing Cascade Failures

What if your Tier 1 retries keep failing? You don't want to retry forever.

A circuit breaker tracks failures and "trips" when too many occur:

Closed (normal): Requests flow through normally

Open (tripped): All requests fail immediately without trying (circuit is broken)

Half-Open (testing): Allow one request through to test if service recovered

Implementation:

Track failure count in a database or variable:

If failures in last 5 minutes > 10:
    Circuit = OPEN
    Skip all API calls
    Alert: "Circuit breaker tripped for [Service]"
    Wait 5 minutes
    Try one request (Half-Open)
    If success: Reset circuit
    If failure: Stay open

This prevents hammering a down service and lets your workflow recover gracefully when the service comes back.

Dead Letter Queues: Never Lose Data

When all else fails, you need a dead letter queue (DLQ): a place where failed records go to wait for human attention.

Requirements:

• Store complete input data (can replay the record)
• Store error details (know why it failed)
• Store metadata (when, which workflow, how many retries)
• Easy to query and filter
• Easy to reprocess

Simple DLQ with Google Sheets:

Timestamp	Workflow	Error	Input Data	Status	Resolved
2026-01-20 02:14	Order Sync	Rate limit after 3 retries	{"order_id": 123...}	Pending

Reprocessing workflow:

1. Filter Sheets for Status = "Pending"

2. For each row: Parse Input Data, run through main workflow

3. If success: Update Status = "Resolved"

4. If failure: Update error, increment retry count