The most dangerous setting in your automation is "continue on error"

A green workflow is not the same as a working one

I have a rule I tell every client during our first call: a workflow that never goes red is not necessarily healthy. It might just be very good at hiding its failures. And the setting that lets it do that is sitting right there in the configuration, one click away, labeled something harmless like "Continue on error."

It is, in my experience, the most dangerous toggle in any no-code stack. Not because it is hard to understand. Because it quietly turns a loud problem into a silent one, and silent problems are the expensive kind.

The setting that ate forty orders

Here is the case that made me start warning people about it. An online retailer synced every order from the shop into their inventory system. The workflow had run for months without a single red run. Everyone was happy. Then a customer called: paid two weeks ago, still no delivery. We looked. The order was in the shop, the payment had cleared, the inventory system had no record of it at all.

It was not a one-off. Over three weeks, about forty orders had simply vanished. No error, no alert, no red run. The cause was one checkbox on one module: continue on error. The step that wrote into inventory occasionally hit an API timeout, the kind of thing a retry would have fixed instantly. Instead the workflow shrugged, dropped the order, and moved on to the next one.

Why the setting exists in the first place

To be fair, it has real uses. Make calls it "Continue," n8n calls it "Continue On Fail," Zapier handles it through per-step error settings. The mechanic is the same everywhere: when a step fails, the workflow keeps going instead of stopping.

Sometimes that is exactly what you want. Picture a step that enriches each new lead with the company logo. If that lookup fails, you still want the lead created. The logo is a nice-to-have, not a reason to block the whole pipeline. Continuing there is the correct choice.

The trouble starts when people flip the switch not as a decision but as a reflex. The workflow goes red, the error emails pile up, it is annoying. Tick the box, the red disappears, peace returns. It feels solved. What you actually did was tell the system it is allowed to throw away anything it cannot process.

Handling an error and ignoring one are different jobs

This is the misunderstanding I find in almost every broken workflow. People think they handled the error. They only hid it.

Handling an error means you catch it and do something useful. You route the failed record into an error branch. You wait and retry. You drop it into a separate list. You fire an alert that a real person actually reads.

Ignoring an error means you catch it and bin it. The record is gone, the run counts as a success, the dashboard stays green. That is what the default checkbox does. It does not handle anything. It swallows.

Green is the most misleading color on the dashboard

A red workflow is irritating, but it is honest. It tells you something is wrong, the moment it goes wrong. A green workflow that is quietly losing data tells you nothing. You find out when a customer calls, when the accountant spots a gap, when the quarterly numbers refuse to reconcile.

That is the real trap. The setting does not remove the problem, it just delays the moment you learn about it. And the later you learn, the more it costs. Forty missing orders on day one is a config bug you fix in ten minutes. Forty missing orders after three weeks is angry customers, manual cleanup, and a nagging question about what else you are not seeing.

It is not a retail problem

The shop is just the case I remember most vividly. The pattern does not care how big you are.

A solo consultant I know synced invoices from her payment provider into her bookkeeping tool. A few failed because a required field came through empty. The result: open invoices nobody chased, because as far as the books were concerned they did not exist. She found out at tax-filing time, which is the worst possible moment to find out.

A mid-sized sales team piped leads from a web form into their CRM. Now and then a field arrived in a format the import did not like, and that lead quietly vanished. Sales never knew it came in. Nobody misses an enquiry they were never told about.

A large company ran a nightly export into their data warehouse. A handful of rows per run failed on a formatting issue and got skipped. The report looked complete. It was quietly wrong. People made calls on numbers that were off by a few percent and never suspected a thing.

The common thread: the record that gets dropped is almost always the odd one out, which is exactly the one you needed to see. And the higher the volume, the more slips through unnoticed. At ten records a day you would spot a gap. At ten thousand you never will.

What good looks like

The reassuring part: doing it properly takes barely more effort than ticking the box. Four habits cover most of it.

Fail loud by default. Let workflows go red when an important step fails. Red is not a flaw, it is a working smoke detector. Just make sure the alert reaches a human who can act on it, not an inbox nobody opens.

When you genuinely need to keep going, catch the failed record instead of dropping it. Write it to a separate table, a dead-letter list. The main process carries on, but nothing disappears. At the end of the day you can see exactly what did not make it through and fix those cases on purpose.

Retry the transient stuff. Timeouts, brief outages, a rate limit you bumped into, none of those are real failures. They are noise. A retry after a few seconds clears most of them before anyone notices.

Reconcile the counts. For the retailer, a daily check would have been enough: how many orders are in the shop, how many in inventory? If the numbers disagree, raise a flag. That single comparison would have surfaced the problem on day one instead of week three.

One question before you tick that box

Before you turn on "continue on error" anywhere, answer one thing: where does the record go that this step cannot process?

If the answer is "into a list I review daily" or "nowhere, the logo is optional," fine. You made a deliberate call. If the answer is "uh, nowhere," then you are not handling errors. You are storing up a phone call from a customer who paid and got nothing.

If you are not sure whether one of your automations is quietly losing data behind a wall of green runs, that is worth checking before a customer does it for you. Our free Automations Check goes through your workflows and points out where a healthy-looking run might not be telling you the whole story.