n8n webhook works in test but dies after the demo
First deployment check: copy the production endpoint from the webhook node, then confirm the external application is using that exact URL. Do not rely on the URL that worked while someone had the n8n editor open.
This catches a very ordinary failure in lead-generation websites and operational automations: a form submission works during a demonstration, everyone nods along, then the editor closes and nothing reaches the live workflow. The form may still show a success message too, which proves rather less than people think.
For a business handling enquiries, bookings, supplier requests or internal handoffs, this is not a cosmetic defect. Events can disappear before a team notices, while the original test is still being treated as proof that the integration was delivered.
The test URL is not the live endpoint
n8n documents separate test and production webhook URLs. A test webhook is registered while the workflow is listening or executing in the editor, whereas the production endpoint requires the workflow to be published in current documentation. Some older installations use an activation label instead, so check the wording in the version you actually run rather than following a screenshot from three years ago.
That distinction is set out in the n8n webhook documentation. A successful Listen for Test Event session proves that a request reached the temporary test listener. It does not prove the external form, CRM or booking platform is registered against the permanent production endpoint.
A sensible rule is simple: test the endpoint the external system will use after the demonstration ends.
Test versus production: compare the two routes
| Check | Test route | Production route | What failure looks like |
|---|---|---|---|
| Webhook URL | Usually contains a test path | Usually contains a production webhook path | The external system still posts to the test URL |
| Workflow state | Editor is listening for an event | Workflow is published or activated for the installed version | Requests arrive only while an editor session is open |
| Evidence location | Visible during manual testing | Recorded in production execution history | Team waits for data to appear in the editor |
| Request method | Often manually selected during testing | Must match the external sender exactly | Sender posts while webhook expects GET, or the other way round |
| Next diagnosis | Did the listener receive anything? | Did an execution start and where did it stop? | An unregistered endpoint is mistaken for a downstream failure |
Production webhook deployment checklist
- Identify the endpoint type. Is the sender a WordPress contact form, a CRM, a payment service, a booking tool or an internal system? Record the exact webhook node and the intended production URL. Do not paste a URL from an old Slack message and hope for the best.
- Copy the production URL from n8n. Place it in the external system’s live webhook registration or form integration setting. Check for an old webhook-test address left behind from a demo or staging setup.
- Confirm the workflow is available for production requests. In current n8n documentation this is publication. On older installations, the equivalent may be described as activation. The important bit is whether n8n has registered the production endpoint, not the label on the button.
- Verify the HTTP method. A webhook configured for POST will not quietly interpret a GET request as a friendly suggestion. Check the sender’s method, content type and any authentication header or secret expected by the workflow.
- Send one controlled live request. Use a clearly identifiable test name or reference, then inspect production execution records. Do not sit waiting in the editor for activity that belongs in the execution history.
- Separate receipt from processing. If no production execution exists, the problem is likely the endpoint URL, publication state, method, registration or network access. If an execution exists but fails later, inspect the failed node, credentials, field mapping or downstream API response.
- Test the final output. A successful execution is useful, but check the actual outcome: did the enquiry reach the correct inbox, CRM pipeline, spreadsheet or task queue? An old inbox address and a valid webhook can still make a business look as though it has gone missing.
One realistic form failure
A service business uses a WordPress form to send new enquiries to n8n. During setup, the developer clicks Listen for Test Event, submits a form, and sees the payload arrive. The form integration is then left pointing at the webhook-test URL.
A week later, a potential client submits the same form. Nobody is listening in the editor, so the temporary route has gone. The website displays its normal confirmation message, the sales team sees no lead, and attention turns to spam folders or WordPress mail settings even though the request never reached the live workflow.
Before broadening the automation work, it helps to define ownership, trigger conditions and failure checks. Our guide to setting the scope for small business automation before switch-on covers the decisions worth settling before live dependencies start piling up.
Where to look when a production run exists
If the production execution record is present, the webhook itself has done its job. Follow the run node by node. Look for a missing field name, an expired CRM credential, a rejected API response, a branch that filtered the event out, or a downstream email action pointed at a mailbox nobody monitors.
That is a different job from an unregistered endpoint. Treating both as a generic webhook problem tends to produce needless rebuilds and a longer outage. For processes involving several teams or manual follow-ups, a business process automation audit of handoffs can help establish where an event should be visible and who owns the next action.
When the fix needs wider automation support
If the workflow handles more than a single form notification, document the production URL, owner, sender, method, authentication, expected payload and final destination. It is basic operational housekeeping, but it stops a live process being dependent on whichever person remembers the demo setup. For broader planning around connected business workflows, see business automation services for practical operational workflows.
Questions about n8n webhooks in production
Where do production webhook executions appear?
Production webhook activity should be checked in n8n’s execution records rather than by leaving the workflow editor open. Find the relevant workflow, locate its executions, and identify the controlled request by its timestamp or unique test value. If there is no execution record, start with URL registration, workflow availability and HTTP method.
Why does my workflow receive data only while Listen for Test Event is open?
Listen for Test Event creates a temporary test listener. It is intended for building and checking the request structure, not for receiving ongoing live traffic. Configure the external system with the production webhook URL and ensure the workflow is published or activated according to the n8n version in use.
Does a form success message prove n8n received the submission?
No. A success message may only confirm that the browser submitted data to the form handler. It does not prove the form handler sent the webhook, that n8n accepted it, or that a later CRM or email action completed. Check the production execution record and the final destination.
Send the endpoint type and the failing request details for a focused live-integration review. Include the request method, the production URL path with sensitive parts removed, and whether a production execution record appears. That is usually enough to avoid poking at a workflow that was never the problem.