An n8n webhook works while you watch but not afterwards: test and production URLs

Two addresses, two states

The n8n Webhook node gives you two URLs, and they are registered at different times. The documentation says the Test URL is registered when you click Listen for Test Event, or run the workflow while it is not active, and that data sent to it appears in the editor. The Production URL is registered when the workflow is published. The page checked uses the word published, so check what your n8n version calls it. The editor does not show incoming data for the production URL. To see it you open the workflow's Executions tab and pick a run.

The most common mistake follows directly. A sender that was set up with the test URL works only while the editor is waiting, and silently has nowhere to deliver after you close it. A sender set up with the production URL before the workflow is published has nothing registered to receive it.

• Copy the URL from the production tab for any sender that must keep working.
• Publish the workflow before pointing the sender at the production address.
• Look for runs in the Executions tab, not in the editor canvas.

A short checklist for a webhook that does nothing

Work from the sender towards n8n. First, which URL did the sender store? A test URL stored in a live tool is the usual cause. Second, is the workflow published, and does the Executions tab show a run for the time you sent the event? Third, what does the sender's own delivery log say about the response it received? If your sender keeps a delivery log, its status code and timing are better evidence than any guess about n8n.

If there is no execution and the sender reports success, the request may have gone to a different workflow or a different n8n instance. If there is an execution that failed, read its error before changing anything.

• Check the HTTP method set on the node matches what the sender sends.
• Check the path on the node matches the path the sender stored.
• Check there is only one n8n instance and one copy of the workflow receiving the traffic.

What the sender sees: respond options

The node's response option decides what the sender is told and when. Responding immediately sends a response code and a short message right away. Responding when the last node finishes returns the output of the final node, so the sender waits for the whole workflow. A Respond to Webhook node lets you shape the reply. A sender with a short time limit will count a slow workflow as a failure and may retry, which then runs the workflow twice. GitHub documents a 10-second limit and Shopify a 5-second request timeout. Answer quickly and do the long work afterwards.

• Choose immediate response for senders with short deadlines.
• Expect retries if the sender saw a slow answer, and make the workflow safe to repeat.
• Read the sender's own documentation for its time limit.

Authentication, signatures and size

The authentication choices the node page lists are Basic, Header and JWT, with an IP allowlist that returns an error to other callers; the maximum payload is 16MB, adjustable on a self-hosted install by an environment variable. An HMAC signature computed over the request body, the scheme many senders use, is not among the options listed on the page checked. Verifying it needs an extra step that works on the exact bytes received, and that step is easy to get wrong. The signature guide explains why.

Being told when it fails

n8n does not tell anyone about a failed execution unless you set up an error workflow. The documentation says an error workflow must start with the Error Trigger node, you choose it in the failing workflow's settings, and it can send an email or a Slack message. The trigger receives the execution and workflow details; the execution ID and URL are available only if the execution is saved. Build it once, share it between workflows, and test it with a deliberate failure.

This guide does not build a signature-checking receiver or tell you how to host n8n. The paid outcomes cover a verified, repeat-safe receiver built as code you control, accepted by tests with altered, unsigned and repeated deliveries, and failure alerts for up to five named automations on one platform, accepted when a deliberate failure on a copy reaches a shared place and two named people.