Error handling and retries

Workflows that process real-world data will fail. Files get corrupted, APIs go down, AI models refuse, networks hiccup. The difference between a workflow you trust and one you don't is how it handles failure. This article covers the three error-handling patterns and when to use each.

The three patterns

Most production workflows combine the first two: per-node handling for the failures you can predict, plus an Error Catcher as a safety net.

Per-node error output

Every workflow node has two outputs:

• Success output — items that processed successfully flow here (this is the default arrow you draw).
• Error output — items that failed flow here, with an error field attached describing what went wrong.

In the workflow editor, the error output is usually a separate connection point on the node (often labeled "error" or shown beneath the success output).

Pattern: notify on extraction failure

[Google Drive Trigger]
        │
        ▼
[Data Extractor]──(success)──→ [Insert Rows] ──→ [Send Slack: #ap-inbox]
        │
        └─(error)──→ [Send Slack: #ap-errors]

The error Send Slack node's message:

Extraction failed for {{$item.data.file.name}}: {{$item.data.error.message}}

Now every failure shows up in #ap-errors with the filename and reason, while successes flow through normally.

Pattern: log errors to a sheet

Replace Send Slack with Insert Rows pointing at an "Error Log" sheet. Useful when you want a permanent record:

[Data Extractor]──(error)──→ [Insert Rows: Error Log]

Map columns:

• Timestamp → {{$now()}}
• Source File → {{$item.data.file.name}}
• Error Message → {{$item.data.error.message}}
• Workflow Run ID → {{$workflow.runId}}

Add a Send Slack node downstream if you want both notification and logging.

Error Catcher node

The Error Catcher is a workflow-level fallback. It catches errors from any node that doesn't have its own connected error output.

[Trigger] → [Node A] → [Node B] → [Node C]
                                       │
                  (any unhandled error from any node)
                                       │
                                       ▼
                              [Error Catcher] → [handle it]

Use Error Catcher when:

• Most nodes don't need specialized error handling, but you want a safety net.
• You want one consistent place to handle all errors (alert, log, metric).
• You're building a workflow with many nodes and per-node error wiring would clutter the visual.

Use per-node error outputs (instead of Error Catcher) when:

• A specific node's failure mode needs a specific response (e.g., extraction failures go to AP team; API failures go to engineering).
• You want to retry only certain nodes without re-running the whole workflow.

You can use both — per-node outputs for the predictable failures, Error Catcher for everything else.

Stop on error

Each node's Settings has a Stop on error option. When enabled:

• The first error halts the entire workflow run.
• Subsequent items aren't processed.

Use this only when:

• Processing one bad item would corrupt downstream data.
• You'd rather stop and investigate than process partial results.

The default (off) is almost always what you want — one bad invoice shouldn't stop processing the other 99.

Retries

Each node's Settings has a Retries option. When enabled:

• If the node fails on an item, Lido waits a configured backoff and retries.
• After all retries are exhausted, the item flows to the error output (or halts if Stop on error is on).

Use retries for:

• Transient API failures — rate limits, momentary network issues, brief downstream outages.
• AI provider hiccups — occasional 429s or 5xxs from the upstream model provider.

Don't use retries for:

• Logical errors — a bad column mapping won't get better on retry.
• AI extraction issues — if the AI returns garbage, it'll return the same garbage again.
• Auth failures — wrong credentials won't fix themselves.

Recommended: 3 retries with exponential backoff for any API/AI-calling node. None for pure data transformations.

Worked example: invoice pipeline with full error handling

[Google Drive Trigger]
        │
        ▼
[Edit Item: attach run metadata]   // timestamp, file name, run ID
        │
        ▼
[Data Extractor]
        │
        ├──(success)──→ [Insert Rows: Invoice Tracker]
        │                       │
        │                       ▼
        │                [Send Slack: #ap-inbox]
        │
        └──(error)────→ [Insert Rows: Error Log]
                                │
                                ▼
                        [Send Slack: #ap-errors]

[Error Catcher: anything unhandled] → [Send Slack: #infra-alerts]

What this gives you:

• Successes are tracked, logged, and announced.
• Extraction failures go to the AP team (they can re-upload or manually process).
• Anything else (Insert Rows fails, Slack token expires, etc.) goes to infra.

Three years from now when this workflow has run 100,000 times and something goes wrong, the team will know exactly where to look.

What to put in error messages

Make error messages actionable. The person seeing them should know what to do without opening Lido.

Bad: "Error: extraction failed."

Good: "Extraction failed for 'invoice-vendor-X-2026-04-12.pdf': AI provider returned no data. Possible causes: encrypted PDF, unsupported format, or content filter triggered. Re-upload an OCR'd version or contact AP team."

You don't have to write essays — just enough that a non-technical teammate can take action.

Tips

• Always wire up error outputs on Data Extractor and API Request nodes. They're the most likely to fail.
• Use a single Error Log sheet across all your workflows. Easier to monitor than chasing errors per-workflow.
• Add {{$workflow.runId}} to error messages. Makes log correlation possible.
• Set retries on AI and API nodes only. Other nodes either succeed deterministically or fail logically.
• Test the error path. Drop a corrupted file in to confirm errors actually flow through your error handling. Discovering broken error handling during a real outage is the worst time.

Common mistakes

• No error handling at all. Failures disappear silently and you only notice when someone asks "where's the data for that invoice?"
• Using both Error Catcher and per-node outputs without thinking about which catches what. Per-node outputs win — Error Catcher only catches errors that don't have a connected per-node output.
• Retrying logical errors. Configuration mistakes don't fix themselves; retrying just wastes plan pages.
• Stop on error in production. Halts everything for one bad item. Almost never what you want.
• Cryptic error messages. "An error occurred." Useless. Write messages a teammate can act on.
• Untested error path. You won't know your error handling is broken until you need it.

Related articles

• Build your first workflow
• Triggers: how workflows start
• Nodes reference (overview) — Error Catcher node
• Improve extraction accuracy
• Send extracted data to email or Slack

Updated on: 16/04/2026