How to stop one bad record killing your whole workflow

Most first-draft workflows are built to succeed. Every node is wired for the happy path, and every node's error setting is left on the default, which in n8n means "stop the workflow." That is fine for a demo. It is fatal in production, because the first time a webpage times out, a PDF comes through malformed, or an API returns a rate-limit error instead of data, the whole run halts. Not just that record. The batch behind it too.

A builder running a scraping and enrichment workflow for a real estate client watched this happen with a single unparsable listing page: ninety-nine good records queued up behind one bad one, and none of them got processed until someone noticed the workflow had silently stopped hours earlier.

Find out where it actually breaks first

Before touching error settings, run the workflow against real data and watch for where it dies, not where you assume it will die. VIN decoding, PDF parsing, and any step that shells out to a third-party API are the usual suspects, because they are the steps you do not control. Rate limiting shows up constantly here too. An API that works fine at ten calls a minute starts throwing 429s at sixty, and a workflow with no handling for that error code just stops rather than backing off and retrying. Pull up the execution log for a failed run and read the actual error, not the summary. It is often a formatting mismatch, like an error handler built for one API's response shape breaking silently when a second integration returns errors in a different structure.

Switch the failure points from stop to continue

Once you know which nodes fail, change their error behavior one at a time rather than flipping every node in the workflow at once. n8n's "continue using error output" setting routes a failed item down a separate branch instead of halting execution, and "always output data" keeps a node from silently swallowing a record that came back empty. Pair that with a conditional check further down the workflow that filters out the failed items and lets the rest continue. This is also where a merge node earns its place: if you split the flow into a success path and a failure path, the merge step is what stops the failure branch from sending a false "all done" signal before the good records have actually finished processing.

Give every failure somewhere to land

A record that fails silently is worse than one that fails loudly, because nobody notices until a client asks why they never got their report. Route failed items to a sheet, a table, or a flagged status field, so failures are visible without anyone digging through logs. For anything client-facing, add a notification, even something as blunt as a message that fires when three retries have all failed. Retry logic with two or three attempts before giving up catches the transient failures, the timeouts and momentary rate limits, without masking a genuinely broken integration behind endless silent retries.

Decide what still needs a human

Not every failure should auto-resolve. A missing field or a duplicate record is worth a manual review step rather than a guess, and an upsert pattern instead of a plain insert prevents the duplication that shows up once retries start reprocessing records that partially succeeded. Build this in after the end-to-end flow already works, not before. Error handling bolted onto a workflow that has never successfully run once just hides the fact that nothing works yet.