n8n Webhook Errors: Fix 500s, CORS & Failed Triggers

An n8n webhook error almost always traces back to one of a few causes: the workflow is not active so the production URL is not registered, the caller is hitting the test URL instead of the production one, a browser request is blocked by CORS, the path returns a 404 because it was never registered, a long workflow times out before responding, or an auth or signature check fails. This guide walks through each symptom, the likely cause, and the fix — then covers why webhook failures are so easy to miss and how to catch them across runs.

500: Problem running workflow

A webhook that returns a 500 with a message like Problem running workflow means the request reached n8n and triggered the workflow, but a node inside it threw before the workflow could respond. The webhook itself is fine — the failure is downstream. Open the Executions list, find the run for that request, and read the errored node's input to see what broke, exactly as you would for any failed execution.

The trap is that the caller only sees a generic 500. The real error — the node, the message, the payload — lives in n8n, and the person who made the request cannot see it. So a 500 is your signal to go look at the execution, not to touch the webhook node.

Test URL vs production URL, and 404 not registered

This is the single most common n8n webhook problem. Every Webhook node has two URLs: a test URL that only listens while you have the editor open and have clicked Listen for test event, and a production URL that only works once the workflow is toggled Active. Call the test URL when you are not actively listening, and nothing happens. Call the production URL while the workflow is inactive, and n8n returns a 404 saying the webhook is not registered.

The fix is almost always the same: use the production URL, and make sure the workflow is toggled Active in the top bar. A 404 that reads webhook not registered is n8n telling you the path exists in a workflow but no active workflow is currently listening on it — activate the workflow, or check that you copied the production path and not the test one.

CORS errors from the browser

If you call an n8n webhook directly from front-end JavaScript, the browser may block the response with a CORS error even though n8n received the request and ran the workflow fine. CORS is a browser rule, not an n8n failure — the workflow executed, but the browser refused to hand the response back to your page because the required Access-Control-Allow-Origin header was not present.

Fix it in the Webhook node's options by setting the allowed origins (Access-Control-Allow-Origin) to your site, so n8n returns the header the browser needs. If the front end sends a preflight OPTIONS request first, make sure the webhook is configured to answer it. When you cannot loosen CORS, the safer pattern is to call the webhook from your own backend instead of the browser, so no CORS check applies at all.

Timeouts on long workflows

By default a Webhook node responds only after the whole workflow finishes. If the workflow does slow work — a long LLM call, a big loop, an external API that lags — the caller can time out and give up while n8n is still running, and you get a failure on their side even though the workflow eventually completed successfully.

The fix is the respond-immediately pattern. Set the Webhook node to respond right away (or use a Respond to Webhook node early in the flow) so the caller gets a fast acknowledgement, then let the rest of the workflow run asynchronously. The caller is no longer waiting on your slowest node, and the timeout disappears.

Auth and signature failures

If a webhook has authentication enabled — header auth, basic auth, or a signature check — a request without the right credentials is rejected before the workflow runs, typically with a 401 or 403. This looks like a broken webhook to the caller, but it is working exactly as configured. Check that the caller sends the expected header or credentials, and that they match what the Webhook node is set to require.

Signature verification adds a subtler failure: services like Stripe or GitHub sign their payloads, and if you verify that signature inside the workflow, any mismatch (wrong secret, or the raw body altered before hashing) fails the check even though the request is genuine. Confirm you are validating against the exact raw body the provider sent and using the correct signing secret.

Symptom, cause, fix at a glance

Why webhook failures are easy to miss

The dangerous thing about webhook errors is the asymmetry: the caller sees the failure, and you do not. A 500, a timeout, a rejected auth — those land on whoever made the request, often a third-party system that has no way to tell you and simply moves on. A 404 on an inactive workflow does not even create an execution, so there is no failed run in your log to notice. From inside n8n, everything can look quiet while requests are being dropped on the doorstep.

That is the same blind spot behind silent failures generally: no error surfaces where you would look for it. The way to close it is to watch for failures across runs rather than one execution at a time — rising error rates on an endpoint, a spike in 500s after a deploy, a trigger that stopped firing. The playbook for that is in n8n error tracking and debugging silent failures in n8n workflows.

Catch the webhook errors you never see

You can build detection yourself with an error-trigger workflow and some alerting, or connect a tool that watches for you. Obsivara connects to n8n read-only, tracks execution outcomes across every run, and alerts when an endpoint's error rate climbs or a trigger goes quiet — so a webhook that starts failing reaches you before the caller gives up. See the native connector at /connect/n8n, or run a free 48-hour audit against your real workflows at /free-audit.