If your n8n webhook not receiving data, first check the webhook URL, the Webhook node HTTP method, and that the workflow is activated. Many silent webhooks are caused by inactive workflows, wrong paths or reverse proxy/TLS issues, or queued workflows that choke the instance.
Why this happens
There are four common causes: wrong webhook configuration, the workflow is not activated or the Webhook node is misconfigured, networking or TLS prevents the request reaching n8n, and backpressure where many queued executions overload the instance. You will also see cases where OAuth or authentication rejects the request silently, or the sender uses a different HTTP method or payload format.
n8n webhook not receiving data: step-by-step debug
- Confirm the basics, quickly
- Open the workflow, check the
Webhooknode, verify theHTTP MethodandPathexactly match the sender. - In the top bar, confirm the workflow is turned on by the
Activatetoggle. If it is off, webhooks will not trigger.
- Open the workflow, check the
- Send a controlled test from your machine
Replace
https://your-domain.com/webhook/pathwith the exact webhook URL from n8n UI and run one of these.curl -v -X POST 'https://your-domain.com/webhook/path' \ -H 'Content-Type: application/json' \ -d '{"test":"hello"}'For GET webhooks:
curl -v 'https://your-domain.com/webhook/path?foo=bar'Look for a 200 or other expected response. If you get TLS errors, the command will show them.
- Check n8n execution and logs
- Open n8n UI, go to "Executions" and the workflow’s history. If no execution is recorded, the request never reached n8n or the workflow was inactive.
- Check your process logs or Docker logs for errors like connection refused, TLS handshake failure, or authentication errors.
- Inspect the incoming payload inside the Webhook node
Use an immediate follow node to log data. In a test Code node, print what arrived, for example:
// in Code node return [{ json: { body: $node["Webhook"].json } }];Or reference fields in later nodes with expressions such as:
{{$node["Webhook"].json["total"]}} {{$json["fieldName"]}} - Confirm authentication and headers
- If the sender uses Basic Auth, OAuth, or a custom header, ensure the Webhook node or your reverse proxy accepts it.
- Check if a reverse proxy strips headers or blocks the method. Test direct access to n8n if possible.
- Watch for queue and crash signs
- If many triggers happen at once, n8n may queue executions. Signs include long execution queues in the UI, high CPU or memory, and slow or dropped responses.
- If your instance becomes unresponsive or the process crashes, stop incoming requests by replacing the webhook URL in the sender or pausing the sender, then restart n8n to clear the queue.
Tool specifics and common pitfalls
Self-hosted n8n vs n8n Cloud
With a self-hosted instance, the most common problems are reverse proxy configuration, missing or invalid TLS certificates, and incorrect external base URL. If you use a proxy like Nginx or Traefik, ensure the Host and X-Forwarded-* headers are preserved and that the proxy forwards the exact path to n8n. On cloud-managed n8n, these network issues are less likely, but you still need to activate the workflow.
Nodes and names to check
Check the Webhook node fields: HTTP Method, Path, and any authentication settings. If you call external APIs from n8n, the HTTP Request node uses credentials, so validate those. For in-flow logic or inspection, use the Code node to quickly access {{$node["Webhook"].json}}.
Make.com and Zapier notes
Make.com needs the scenario turned on, and its webhooks module provides a webhook URL you must copy into the sender. Zapier requires the Zap to be switched on. In both, the sending system and the webhook URL must match exactly. The same curl tests above help prove the webhook endpoint works.
Quick one-liner fixes you can run in minutes
- Flip the workflow
Activatetoggle off, wait one second, then on, and re-test the sender. - Restart the n8n process or Docker container to clear stuck queues, then re-run a single curl test.
- If TLS errors appear, temporarily test with HTTP on a private network or use ngrok to verify connectivity, then fix certificates.
- If the sender changed method or payload, update the
WebhooknodeHTTP Methodand use aCodenode to inspect the received body quickly.
How to stop it happening again
- Monitor executions and resource usage. Add simple alerts for queue depth, CPU, and memory so you catch spikes before the instance crashes.
- Document and pin webhook URLs, and automate a health-check that posts a test payload every few minutes to confirm the endpoint responds 200.
- When you expect high volume, add rate limiting at the sender or a buffer queue like a message broker so n8n does not get flooded by concurrent triggers.
When to get help
If you followed the checklist and still have no recorded executions, collect the curl output, n8n logs, and a screenshot of the Webhook node settings, then ask for help. The n8n community thread on queued crashes is a useful reference when the instance is overwhelmed, see the forum post about a complete instance crash due to queued workflows for similar cases.
For help with expressions and referencing node data, this expressions thread shows practical examples for {{$node["Webhook"].json[...]}} usage.
For a quick starter that walks through a working webhook workflow in n8n, see our post on Your first n8n workflow: answering WhatsApp leads automatically, it shows common nodes and the activation step.
If you want hands-on training to build and maintain automations like this, learn with Automate Naija.
Frequently asked questions
Why does my webhook return 404 but the URL is correct?
A 404 usually means the path does not match a registered Webhook node or the workflow is inactive. Check the Path field in the Webhook node, confirm the HTTP Method, and ensure the workflow is activated. Also confirm your reverse proxy forwards the exact path to n8n.
How do I tell if n8n queued workflows crash the instance?
Signs include many executions stuck as queued in the UI, rising CPU and memory, slow or missing responses to webhook requests, and the n8n process restarting. If this happens, pause incoming traffic, restart the instance, and investigate the spike source.
What curl command proves the webhook works?
Use a simple POST or GET to match your Webhook node. For JSON POSTs run: curl -v -X POST 'https://your-domain.com/webhook/path' -H 'Content-Type: application/json' -d '{"test":"hello"}'. Look for a 200 style response and no TLS errors in the output.
How do I reference data from the Webhook inside another node?
Use n8n expressions. For example {{$node["Webhook"].json["fieldName"]}} accesses a field sent by the webhook. Inside the same execution you can also use {{$json["fieldName"]}} to access the current node JSON output.
Build it with us. The community is free and the build track teaches this kind of automation week by week: see pricing or join the community.