n8n in Production: What Breaks When a Workflow Becomes Business-Critical

A workflow that runs fine on your laptop behaves differently once a business depends on it. The failure modes I keep hitting when n8n automations go from demo to production, and what I do about each.

Building an n8n workflow that works is easy. That is the point of n8n, and it is a genuinely good tool.

What is not easy — and what nobody warns you about — is the transition from "this works" to "a company depends on this running correctly at 03:00 on a Sunday while nobody is watching." That transition has specific failure modes, and they are the same ones every time.

These are the ones I keep hitting, roughly in the order they bite.

1. Retries that duplicate side effects

This is the first one and the most expensive.

A node fails on a network blip. n8n retries. The retry succeeds. Except the first attempt had already created the invoice before it timed out on the response — so now there are two invoices, and nobody notices for a month.

Anything that writes to the outside world needs to be idempotent, meaning running it twice produces the same result as running it once. In practice:

  • Send a deterministic idempotency key with every create request, if the API supports one. Many do; almost nobody uses them.
  • If the API does not, check-then-create: query for the record by a natural key first.
  • Order your nodes so the write is the last thing that happens. A workflow that writes and then does five more steps has five more chances to fail after the irreversible part.

The rule I use: before you enable retries on a node, ask what happens if it runs twice. If you cannot answer, do not enable them.

2. No error workflow, so failures are silent

The default failure mode of a broken automation is not an alarm. It is silence, and silence looks exactly like success.

Set an error workflow (Settings → Error Workflow) on every production workflow, on day one. It should do two things: notify a human somewhere they actually look, and include enough context to diagnose — which workflow, which execution ID, which node, and the input data that caused it.

The subtler version of this problem: workflows that fail by doing nothing. A trigger that stops firing produces no error at all, because nothing ran. This is the outage nobody detects for three weeks. The only reliable answer is a dead-man's switch: a separate scheduled check that alerts when the expected run has not happened.

3. The one giant workflow

Every mature n8n installation I have seen has one workflow with sixty nodes that nobody wants to touch. It usually started as twelve.

The cost is not aesthetic. It is that you cannot re-run a failed step in the middle without re-running everything before it, which for anything with side effects means you cannot re-run it at all. So failures require manual repair instead of a retry.

Split at the points where you would want to resume. A parent workflow calling sub-workflows via Execute Workflow costs a little clarity in the editor and buys you the ability to fix one stage without touching the others.

4. Credentials that expire on a holiday

OAuth tokens expire. API keys get rotated by an IT department that does not know your workflow exists. Certificates lapse. All of these produce authentication failures that look like sudden mysterious breakage.

Two habits help. Keep an inventory of which workflows use which credentials — a table somewhere, not tribal knowledge. And make the error workflow's message distinguish auth failures from everything else, because an auth failure has a fixed, known cause and should not consume forty minutes of debugging.

5. Payload size and memory

n8n passes data between nodes in memory. This is fine until someone uploads a 200 MB file, or a query that usually returns 50 rows returns 500,000 because a filter silently stopped applying.

Guard the input. Add an explicit check on batch size early in the workflow and fail loudly if it exceeds what you designed for. "Too many items, aborting" is a much better outcome than an out-of-memory crash halfway through processing, with some records written and some not.

For genuinely large jobs, process in batches with a loop and hold references — file IDs, URLs — rather than passing the file contents between every node.

6. No version history that means anything

The editor is a live production environment. You edit, you save, it is live. There is no pull request, no diff, no review.

The minimum I do now: export production workflows to JSON and commit them to git on a schedule. It is not proper version control — the diffs are ugly JSON and nearly unreadable — but it means you can answer "what changed on Tuesday" and you can restore a working version.

Better, if the workflow matters: separate development and production instances, and promote by importing. Slower, and worth it exactly once.

7. Nobody knows what "working" means

An automation is not correct because it did not error. It is correct because it produced the right output.

This distinction matters most with anything involving an LLM, where the workflow will happily succeed while producing nonsense. But it applies to ordinary automations too: a data sync that runs cleanly and syncs the wrong field is a green tick and a silent problem.

What helps is defining, at build time, one checkable assertion about the output — a count that should match, a total that should reconcile, a field that must never be empty — and having the workflow check it and fail if it does not hold. This is unglamorous and it catches the class of bug that monitoring never will.

8. Self-hosting decisions made once, regretted later

If you self-host — which I do — three things are worth deciding deliberately rather than by default:

  • Execution data retention. n8n stores execution history including the data that passed through it. On a workflow handling personal data, that is a quiet GDPR exposure sitting in your database. Set a retention policy; do not let it default to forever.
  • Queue mode. Regular mode is simpler and fine until concurrency matters. Moving later is a migration; deciding early is a configuration.
  • Backups that include the database. The workflows are in there, along with credentials and history. Backing up the container and not the database means backing up nothing that matters.

The short version

If you take one thing: before a workflow goes live, write down what happens when each node fails, and what happens if it runs twice. Ten minutes with a piece of paper. Almost every production incident I have had with n8n was something that exercise would have caught — and the ones it would not have caught were credential expiries, which is why item four exists.

n8n is not fragile. It is a genuinely good tool that makes building easy enough that people skip the part where they think about failure. The tool is not the problem; the missing ten minutes is.