n8n Workflow Not Working? Find the Symptom, Fix It or Hand It Off

n8n workflow not working? Ten symptoms with the cause and fix, from webhooks that never fire to green runs that lose data, plus when to call a specialist.

By Carlos Familia, CRM & AI automation expert. Updated October 17, 2026. 7 min.

Nineteen data sources went into one n8n workflow, and only two of them ever reached the output. The workflow, posted on r/n8n, pulled job listings, scored them with AI and sent the best matches by text. It ran every few hours and stayed green for months.

The author found the problem only by opening the wiring diagram: just 2 of the 19 sources fed the step that combined the results. The other 17, including a paid API at $25 a month, fetched real data that went nowhere. In the poster's words: "A green run only means nothing threw an error."

When an n8n workflow is not working, work out which of three things is true. It never started, it started and stopped, or it finished and did the wrong thing. The ten symptoms below are ones I have repaired or caused myself. Fix the first few on your own if the workflow touches no customer. Call a specialist when customers receive its messages, when money moves, or when you have read the workflow for half an hour and still cannot say what it does.

"It ran green, but data went missing"

Cause. Green means no node threw an error, nothing more. Replies in that thread suggested a count per source after the merge: fetched, reached the merge, filtered out. My own version of the bug was quieter. A daily call queue I built for a mortgage brokerage finished its first live run with no error, yet rate limits (HTTP 429) had eaten 28 contact reads and 16 tag writes.

Fix. Count items at every join and put failure counters in the run result. I added retries with backoff and capped concurrency at 4. After that: 118 of 118 reads, 43 of 43 tag writes, and the run time fell from 152 seconds to 29.

"The webhook works when I test it, not for real"

Cause. n8n registers a test webhook only while you listen for a test event or execute a workflow that is not active. The production webhook registers when you publish, and its calls show up in the Executions tab, not in the editor. Often the sending system still points at the test URL.

Fix. Copy the production URL, publish, send one real event and look in Executions. One more trap: a partial update to an active workflow once left its webhook dead until I deactivated and reactivated it. Fire a real test event after every change.

"I can't find the run that failed"

Cause. n8n prunes execution history by default. The documented defaults delete data after 336 hours (14 days) and keep at most 10,000 executions. I once left a test on a schedule that fired every few seconds, and the flood pushed that instance's history down to about two days. Runs parked in a Wait for longer than roughly 65 seconds also did not show in the list.

Fix. Choose the retention on purpose. Never test on a seconds-level schedule. Look for waiting runs separately before you conclude nothing is stuck.

"Nobody told me it failed"

Cause. There is no error workflow, or there is one that was never published, and an unpublished error workflow never runs. Even a published one can alert into a dead channel. At a mortgage brokerage, a WhatsApp alert step kept reporting "accepted" for days while the platform had no access to the business account.

Fix. Attach a published error workflow to every active workflow, break one on purpose, and send the alert through the channel the owner actually reads. Setting this up is the core of an n8n consultant review.

"The sender got a 200, but nothing happened"

Cause. If a Code node throws, the webhook can still return a plain 200 to the sender. A Respond to Webhook node sets its status code under its options. The worst version I have seen was outside n8n: a lending marketplace's contact form route wrote each submission to a log, said "success" and kept nothing. Every enquiry since launch was gone.

Fix. Set status codes yourself and test the failure path on purpose: break the save and watch what the visitor sees. I rebuilt that form to run through n8n, and it now answers 502 when anything fails.

"My Code node timed out, or says something does not exist"

Cause. Per-item mode does not reset the Code node's 300-second clock, because the limit covers the entire node. Some sandboxes also lack $helpers and new URL(), and a bare catch swallows that error. n8n's own page says the Code node cannot make HTTP requests and points to the HTTP Request node instead.

Fix. Split big jobs with SplitInBatches so each item gets its own time budget. A wholesaler's nightly summary job produced zero writes on a night with 32 contacts. After the split, the same 32 contacts finished in 354 seconds. Remove bare catches so errors reach your alerts.

"n8n in Docker can't reach my other service"

Cause. Inside a container, 127.0.0.1 is the container, not the server. For an English academy's message classifier, n8n could not reach the local language model until I used the host address Docker exposes, 172.17.0.1 on a default setup.

Fix. Point n8n at the host's address or put both services on one Docker network, then test one real call from inside the container.

"I changed it and it got worse"

Cause. Fetching a workflow can hand you the saved draft instead of the version that is running. I once edited that draft and published it over a live chat router, and the router was down for 15 minutes on stale code.

Fix. Start every patch from the published version. Diff the running version against the saved one, and replay whatever came in while you worked. Keep a way to roll back.

"The AI agent invents answers"

Cause. Usually the agent cannot see its tools. On one booking bot, every tool result arrived as an empty string, and the agent filled the gap with made-up times, prices and bookings. On another, the HTTP tool node failed each call with "Invalid URL". A script that rebuilt only the main connections stripped 23 model, memory and tool links, while executions kept showing success.

Fix. Open a real execution and read one tool result. Clone a working agent instead of building one from raw requests. After any scripted edit, count the AI connections and send a chat that has to call a tool. The full list is in my n8n AI agent mistakes.

"Everything is slow, or n8n returns 502"

Cause. Sometimes n8n is the victim. My hosting provider once throttled a VPS of mine until CPU steal sat between 87 and 90 percent. Part of that load was my own doing: a database stack on the box checked its health every 5 seconds.

Fix. Check the server's CPU, memory and steal figures before touching a workflow. The watchdog behind a Pennsylvania med spa's lead caller only speaks up with evidence in hand, and it flagged a throttling outage without anyone asking. Hosting questions are in n8n self hosted setup.

When do I stop fixing it myself?

Hand it off when a customer receives its messages, when money or contracts depend on it, when the same symptom comes back twice, or when nobody can explain what a workflow does. The poster above needed a wiring diagram to find a problem months old. A specialist starts in the same place: an inventory, a ranked risk list and alerts.

Before anyone edits your live workflows, agree the scope in writing with an n8n project scope of work. The interview questions tell you who to trust with the repair, and what an n8n developer costs tells you what to budget. To stop the next surprise, plan for n8n maintenance. Or book a call and bring your execution list.

Which symptom points to which fix?

About the author

Carlos Familia, CRM & AI automation expert. GoHighLevel, n8n, AI agents, servers. Full-stack developer.

I build CRM systems in GoHighLevel, n8n automations on my own servers and AI voice and chat agents for service businesses. Full-stack developer: I write the workflow, the API integration, the database and the server it runs on, and I test every build with real journeys before handoff.