n8n Webhook Not Firing — The Silent Killer of Automation Workflows

The toggle is on, so the webhook is working. That belief is wrong, and it is the most expensive wrong belief in n8n.

A webhook can be registered, active, and green while nothing reaches it. One operator I know found a client’s lead form had collected 31 entries over two days. All 31 had vanished somewhere between the website and n8n. The workflow showed active, the trigger node showed green, and the execution log was completely empty. No errors. No failed runs. Just an active workflow listening to silence. The form was sending; n8n was not receiving; and nothing in the interface said so.

That is the thing about a webhook. When it stops firing, it does not break in a way you can see. It just goes quiet, and quiet looks exactly like working. Here is what is actually happening under the hood, and why n8n cannot tell you.

What a webhook actually is, and why “active” lies

A webhook is not a thing n8n does. It is a thing the outside world does to n8n. The sender (your form, your CRM, some other tool) makes a call to an address, and n8n either is listening at that address or it is not. The toggle being on does not guarantee a call ever arrives. It only governs whether n8n would catch one if it did.

So the fastest check is the address itself. n8n generates two URLs for every workflow: a test URL (/webhook-test/) that only answers while you have the editor open, and a production URL (/webhook/) that answers when the workflow is active. Two different addresses. Point a live system at the test one and every call sails into nothing, zero executions, zero errors, identical to a total break. Click the webhook node, copy the production URL, confirm the sender uses that one, confirm the workflow toggle is on, fire a test payload, and check executions. A run appears, you are done.

Walk the path the call takes

The call travels from the sender to n8n. It can die at any point along that path, and each point fails differently. Walk it in order.

1. The sender is pointed at the wrong address. The webhook works when you click “Listen for test event” but nothing arrives in live use.

“When I use the production webhook URL in the Evolution API, no requests appear in the Executions tab.”

— israel_silvestre on n8n Community Forum, 2025-04-18

Compare the URL in your sending system against the production URL in the webhook node, character for character. A test URL on a live sender logs nothing, which reads identical to a broken webhook but is an entirely different problem.

2. The endpoint was never registered. The production URL returns nothing, or the sender reports a connection error the instant it tries. Look at the activation toggle, top right of the editor. Reads “Inactive,” and the production endpoint does not exist, because n8n only stands up that listener when the workflow is active. Editing a workflow in some n8n versions silently deactivates it, and saving without re-activating leaves the endpoint dark. If the whole workflow stopped, not just the webhook, the wider diagnostic is in n8n Workflow Stopped Working.

3. The call arrives but the shape changed. The webhook fires, n8n receives data, then a later node fails on a field that is no longer there. Open the latest failed run and read the raw payload in the first node. The sender renamed a field after a CMS or CRM update and told nobody downstream. Here the alert quality is everything. Useless: TypeError: Cannot read property 'email' of undefined at node: Set User Data. Useful: Webhook received data but the field "contact_email" is missing, the sender may have renamed it in a recent form update.

4. A firewall ate it. The sender reports a clean, successful POST, and nothing reaches n8n. Check whether the sending tool has an outbound IP allowlist. Plenty of enterprise tools only call pre-approved addresses, and if your n8n IP is not on the list the request gets rejected before it ever leaves the building. Both logs look clean. You only see it when you put them side by side.

“Sometimes it does not fire… it sometimes fires, and sometimes not due to slow server response.”

— LorenzoG on n8n Community Forum, 2025-08-28

5. n8n was too slow to answer. Some calls land, some do not, no pattern, usually worst when the server is busy. Look at your instance’s CPU and memory at the times the missing calls should have arrived. Most senders wait about 5 to 10 seconds for an answer, then give up. An overloaded n8n misses the window, the sender drops the connection, and n8n never logs a call it never finished receiving.

Why n8n stays quiet about all of this

Every failure on that path has one thing in common: from n8n’s side, nothing happened. A call that never arrived is not an event. n8n can only log what it receives, and the whole problem is that it received nothing. That is why “active and green” tells you so little. The interface is honestly reporting on the one thing it can see, which is the part that was never broken.

Closing that blind spot means watching the workflow from the outside, where the missing calls actually show. NoCrash sends a known payload through your webhook on a schedule and tells you in plain language the moment the runs stop landing, so you find out the same hour instead of two days and 31 lost leads later. Connect your n8n free at nocrash.io and the next silent webhook gets caught while it is still one missing entry. The full pattern lives in How to Know If Your Workflow Is Running and My Automation Broke and I Don’t Know Why. A two-day gap costs you 31 leads. A five-minute gap costs you five minutes. You only get to pick which one you build for.