Your n8n workflow tests green in the editor. You activate it, walk away, and days later discover it never ran in production — no errors, no alerts, no trace. Here is the debugging map for why that happens, and the five checks that catch it before your customers do.
The green-editor lie
n8n's editor and n8n's production runtime are two different machines. The editor executes your workflow locally, discovers nodes at test time, and uses the test webhook URL. Production executes headlessly, often in queue mode behind a load balancer, and only listens on the production webhook URL — and only when the workflow is Active. Everything that follows flows from that single gap.
The activation trap
Every Webhook node owns two URLs. The test URL (/webhook-test/...) responds only while the editor is actively listening and auto-expires. The production URL (/webhook/...) is dead unless the workflow toggle is set to Active. The most embarrassing outage in self-hosted n8n history is sending traffic to the test URL and assuming silence means success — webhooks acknowledge the request and then drop it without a run record.
Fix habit: after activating, fire a real request at the production URL and confirm an execution appears in the Executions log. One manual probe beats a week of dashboard-worshipping faith.
Killer 1 — The localhost shadow
If your exported workflow JSON contains http://localhost, 127.0.0.1, or a machine hostname, that URL resolved to something on your laptop and resolves to nothing on the server. In queue mode it gets worse: the worker that executes the node may be a different container than the one answering your browser.
Killer 2 — Open webhooks
A production webhook without authentication is a public door. Anyone who scans your endpoint can trigger the workflow — spamming downstream APIs, burning your quotas, or injecting malformed payloads that crash the execution silently. Check every Webhook node for an auth header, HMAC secret, or signature validation.
Killer 3 — Secrets sitting in your exports
n8n export:workflow dumps the structure, and structure often carries connection hints, embedded headers, and occasionally raw keys pasted into HTTP nodes. If that JSON ever lands in a Git repo, a Slack channel, or an AI chat, those secrets are compromised — and you will never get a notification when someone uses them.
Killer 4 — Broken node references
Duplicate a workflow, rename a node, delete a dependency — and expressions like $node["Old Name"] keep pointing into a vacuum. The render rarely fails loudly; it fails quietly, downstream, after the webhook already acknowledged the request.
Killer 5 — Missing retries
Production APIs throttle, DNS hiccups, containers restart. A workflow with zero retry-on-fail configuration converts transient 60-second network noise into permanent data loss. n8n defaults to no retries on most nodes.
The 60-second pre-deploy move
Before you trust a deployment: export the workflow JSON and paste it into the free n8n workflow audit — five deterministic checks run entirely in your browser (the file never leaves the tab, no account, no upload). It flags exactly the five killers above in under a minute.
Where the free audit stops
Honesty builds rankings, so: the free tool runs 5 checks. Production workflows face 24 documented failure rules — the full n8n Reliability Kit ($39 $19 launch, disclosing: this is mine) ships all 24 rules, 21 copy-paste fixes, and a print-it-laminate-it PDF checklist for your deploy wall.
But even if you never buy: run the five free checks. Silent production failures are the most expensive bugs in self-hosted automation — and the only ones nobody files an issue about.
Top comments (0)