n8n workflow keeps failing in production: find the cause upstream

You open n8n and there it is again, a red node in the execution list. You retry the run by hand, it works, you close the tab. Two days later it fails again, except this time it ran halfway, created a contact in the CRM, and died before the email went out. Now you have a duplicate contact and a customer who never heard back.

We fix workflows in this state most weeks. The causes repeat. Below is the order we use to find the cause, and what we change so it stays fixed.

Why your n8n workflow keeps failing in production

The mistake almost everyone makes first is treating the failing node as the problem. Someone sees the HTTP Request node erroring, switches on Continue On Fail, and moves on. The workflow now finishes green while doing the wrong thing. That is worse than failing loudly, because nobody looks at a green run.

A red node shows you where the failure surfaced. The cause usually sits a few nodes upstream, or outside n8n altogether.

In the rescues we have scoped, the same handful of causes come up again and again. External APIs fail occasionally no matter how well built they are, and a workflow with no retry turns every blip into a dead run. One lead-routing flow we looked at failed about once a day at roughly 200 runs a day, and its only alert went to a Slack channel that had been archived months earlier.

Nobody had seen a single one.

Webhook timeouts are the second big one. The workflow does heavy work inside the webhook path, the sender gives up after 30 seconds, marks the delivery failed, and often retries, so you get duplicates on top of the failure. Respond immediately, then process in a separate execution.

Then there are the changes nobody connects to the workflow:

• The provider deprecated an endpoint. It worked for a year, then returned 410 one Tuesday, and nobody on your side touched anything, which is exactly why nobody looked there.
• Someone in sales renamed a custom CRM field or deleted a pipeline stage.
• An OAuth token got revoked or a colleague changed a shared password. This one at least announces itself as a 401, if anyone reads the log.
• Volume grew. A flow that handled 50 records a day hits 429 at 500, and n8n treats a rate limit like any other failure. A Split In Batches loop over 10,000 items with full JSON payloads eventually exhausts the instance's memory, and because that depends on how much data arrived that day, the failure looks random.

Four checks before you change a node

1. Read the error body. The red badge tells you nothing. Open the failed execution, click the failing node, and read the full response. A 401 is credentials. A 404 or 410 is a changed endpoint or a deleted record. A 429 is rate limiting. A timeout with no response at all is the network or an overloaded service downstream. The status code on its own rules out half the candidates.
2. Look at the runs around it. Pull up the executions just before and after the failure. If the same node succeeded at 09:12 and failed at 09:13 with similar input, you are looking at the external service, and the fix is a retry.
3. Isolate the node. Pin the input data from the failed execution and run only that node. If it fails with pinned data, the problem is the node or the external service. If it passes, the data reaching it in production is different from what you assume, and you need to compare that pinned input with what a healthy run looked like a month ago.
4. Find the date. Failures that start on a specific day have a cause with a date on it. Ask whether anyone touched the CRM configuration, rotated a key, upgraded n8n, or whether the provider shipped an API change. Read the provider changelog. Most sudden failures we get called about trace to a change that nobody thought was related to the workflow.

Hardening

Fixing the immediate error gets you back to the fragile state you started in. One more hour buys you a workflow that stops interrupting your week. Retries, dead letters and an alert a person reads are the opening items on the production-ready checklist we hand to clients.

Turn on retry on fail for every HTTP Request node that talks to an external service, with 3 to 5 attempts and a growing wait between them. Retry on 429 and on 5xx. Do not retry on 400 or 401; those will never succeed and the retries only delay the alert.

Set an error workflow. n8n can run a separate workflow on any failure, and it should capture the workflow name, the execution URL, the node, and the error message, then send that to a place a human reads every day. My opinion, after a few dozen of these: logging without alerting is worth almost nothing, and it is the second of the five failures that kill automations in production. Every business that has called us after a month of silent failures had logs. None of them had an alert that reached a person.

Make reruns safe. Before creating a record, check whether it exists already, keyed on something stable like an email address or an external ID, or use the upsert operation where the node offers one. Once a rerun cannot duplicate anything, retrying a failed execution becomes a click.

Know when to stop

If the log points at one clear cause, everything above fits in an afternoon. It does not always. Stop and get help when the failures are intermittent with no pattern, when the workflow has grown past 40 or 50 nodes and nobody can trace a record through it, or when fixing one node keeps surfacing a new failure two nodes later. Those are design problems, and patching them one red node at a time is how a workflow becomes unfixable. Occasionally the right answer is a rebuild, and how we decide whether to fix or rebuild a broken automation goes in the diagnostic instead of a bill for patches.

If you want a second pair of eyes before you spend anything, we do a written diagnostic for $500. Within 3 business days you get a document naming what is failing, why, and a fixed quote to repair it, and the $500 comes off that quote. Most n8n repairs land between $750 and $1,500 and take 2 to 5 days, with a 30-day bug warranty. Start at our rescue service or send us the symptoms.