GUIDE · Troubleshooting
n8n Workflow Not Running? The 6-Stage Fix That Finds It in Minutes
2026-10-20 · William Ayad · 8 min read
Stage 0 — Accept the uncomfortable truth first
When a self-hosted n8n workflow is not running, the debugging hour splits cleanly in two: the part where everyone stares at the workflow canvas, and the part where the actual cause — which lives outside the canvas — goes uninvestigated. The canvas was already green. The editor already said the workflow works. The fix always starts by leaving the editor and walking a ladder of external facts, lowest-cost check first. This is that ladder; rungs one and two account for roughly 80% of all real cases.
Stage 1 — Activation state (the 30-second suspicion)
Inactive workflows never run. That sentence deserves its own paragraph because «inactive» hides in ordinary actions: the toggle that flipped back after you edited one node, the import that brought the workflow in inactive by design, the activation that died quietly when a credential expired. Open the workflow and look at the toggle before you touch anything else. While there, note the save state — an unsaved edit after activation is the second-most-popular way the world loses a scheduled day.
Stage 2 — The trigger registration (manually vs. automatically)
Manual runs in the editor route through the editor environment; scheduled runs route through the trigger system. For webhooks, that means the production URL, not the test URL that only breathes while the editor listens — the webhook-not-firing ladder dissects that case fully. For schedules (Cron, Interval), confirm the schedule actually registered: a server timezone mismatch or a stale registration after restart can leave a Cron-level workflow with no heartbeat at all.
Stage 3 — Executions log: did n8n even try?
The Executions panel is the decision point of the whole ladder. Executions present with errors → the trigger fired and your bug lives in nodes: wrong expression, mapped field renamed upstream, API rejecting a payload. Executions absent entirely → your bug lives upstream of execution: webhook reachability, scheduler, queue infrastructure. Two radically different hunts; the log tells you which one you are on. Bookmark this instinct — every faster troubleshooter alive does it on autopilot.
Stage 4 — Credentials and environment on the server
The credential exists. The credential works on your machine. Is it present, unexpired, and readable by the executing process — which, in queue mode, is not even the process you just stared at in your browser? OAuth tokens die, environment variables move between containers, credential files fail to mount in new deployments. For the deeper infrastructure shape of this trap, the queue-mode reliability piece lays out where execution actually happens when main and workers are split.
Stage 5 — The network path (proxy, firewall, reachability)
Especially for webhook-driven flows: does any traffic complete the trip from outside to the n8n process? A reverse proxy stripping the path prefix, a WAF rule blocking POST bodies, a Cloudflare bot fight aimed at your legitimate sender — all produce a perfectly Active workflow that receives nothing. Probe from outside with curl against the production URL and compare what you see against what the stage-3 log shows you.
Stage 6 — When the ladder keeps ending at "infrastructure"
If the fault keeps resolving to queue workers, Redis connectivity, or webhook-registration drift, your correct next read is queue-mode reliability notes — worker starvation and broker reconnections are their own class of silent killer. And if you want to shrink the next scramble from hours to minutes: export the suspect workflow and paste it into the free n8n workflow audit. It flags activation traps, environment-local URLs, and missing retries deterministically — the three upstream causes your ladder just spent the most time eliminating by hand.
Where the free audit stops (honesty first)
Five structural killers — that is the free tool's envelope, disclosed plainly. It does not watch run-time behavior, check external API health, or triage execution logs. The 24-rule preflight and 21 documented fixes for the infrastructure layer live in the n8n Reliability Kit, one-time $39 (disclosing: mine), browser-local like the free tool. The ladder from this piece lives there too, expanded into the full production runbook.
Leave the editor. Walk the ladder. The workflow is always exactly where the evidence says it is.
Check the suspect workflow's export while the ladder is fresh: