One Bad Row Killed the Whole Batch: Partial-Failure Handling for n8n Loops

Description and use

A single bad record halted an entire n8n batch. The fix is to isolate per‑item failures, collect them into a dead‑letter list, and report processed, failed, skipped, and retried counts.

Problem

A single malformed record caused an entire nightly batch of lead processing to stop, leaving hundreds of good records unprocessed.

Outcome

The batch loop now completes fully, failures are isolated and retried individually, and reporting distinguishes between processed, failed, skipped, and retried items.

Workflow

• 1. Run per-item sub-workflow or error-handling branch to capture failures without throwing.
• 2. Return success or structured failure record to the main loop.
• 3. Collect failures into a dead-letter table with business key, error, and raw payload.
• 4. Report counts of processed, failed, skipped, and retried items.
• 5. Retry only items from the dead-letter list, applying dedupe checks.
• 6. Mark retried items as done or keep them on the list if they fail again.

Evidence

A nightly workflow of mine processed a batch of new leads: enrich each one, score it, write it to the CRM. One night a single lead had a malformed phone field, the enrichment node threw, and the execution stopped.

Source

First, isolate failures to the item that caused them. In n8n this means the per-item work runs where an error cannot kill the loop: a sub-workflow executed per item, or an error-handling branch that catches the failure and returns it as data instead of throwing.

Source

Second, collect failures into a dead-letter list, not a log line. A failed item goes into a table with the item's business key, the error, and the raw payload — everything needed to reprocess it without re-running the whole batch.

Source

Third, report four numbers, not one status. Processed, failed, skipped as duplicates, and retried.

Source