Your automation works while you watch the editor, then stops when a real customer submits a form. Or the sender reports a successful request, but no useful business record appears. When an n8n webhook is not working, rebuilding the entire workflow can conceal the actual fault.
Quick answer
Start by matching the sender’s exact URL and HTTP method to the intended webhook, then check whether the request created an execution. That separates registration and network problems from response handling and downstream processing. Test with a harmless, traceable event before replaying real business activity.
Key takeaways
- Match the sender URL and HTTP method to the intended webhook.
- Separate request arrival, workflow execution, acknowledgement, and completed business work.
- Preserve authentication and use a harmless traceable event for diagnosis.
This documentation-based guide was reviewed on October 9, 2026. It covers the generic Webhook node, not every app-specific trigger. Examples are illustrative, not reported test results. Interface labels and configuration names can vary by installed n8n version; verify them before changing a production system.
Define what “not working” actually means
Write down the expected result in business terms. “Create one enquiry record and acknowledge the sender” is more useful than “make the webhook green.” A connection can accept a request while a later step fails to save the enquiry.
Choose one affected event and preserve its event identifier, timestamp with timezone, sender delivery record, destination, method, status code, and response body. Keep credentials and customer payloads in an approved private workspace rather than a shared incident chat.
Ask which boundary has evidence of success. Did the source attempt delivery? Did the public endpoint answer? Is there an n8n execution? Did the target application save the intended record? Treat each answer as a separate checkpoint.
A blank canvas after a production request is not enough to establish failure. Your investigation should follow the event through the appropriate execution history and destination records. Otherwise, an editor-display difference can be mistaken for a lost customer submission.
Check the test URL and production URL first
The official webhook development guide distinguishes test and production URLs. For testing, select Listen for test event before sending to the test URL; the documented listening window is 120 seconds. For production, save and publish the workflow, use its production URL, and inspect executions rather than expecting incoming data on the editor canvas.
Copy the displayed address from the intended node. Compare it character by character with the sender’s saved destination, including scheme, hostname, path, and any required query parameters. Do not reconstruct the address from memory or another environment’s example.
For an illustrative lead form, the developer might test against a temporary listening address while the live form still points to that address. The test succeeds during development, but future submissions do not have an active listener. Correct the sender’s approved destination instead of keeping a manual testing session open forever.
Record which workflow version the team expects to receive live traffic. If a new version was prepared but not published, reconcile that state before more tests. Coordinate changes with the workflow owner so that another colleague does not restore the old destination during the investigation.
Match the request method and route
Opening a webhook address in a browser is not an equivalent test for every sender. Establish the method used by the original service, then compare it with the node configuration. A POST integration should be investigated with an authorized POST test, not merely a browser visit.
The Webhook common-issues reference documents matching request methods, an option for multiple methods, and one registered webhook per path-and-method combination. It also explains that n8n Cloud requests can time out with a 524 response after 100 seconds without a webhook response.
If a path is already in use, identify the owner and purpose of the existing route. Do not unpublish an unfamiliar workflow to make the warning disappear. Agree on a unique path or a deliberate routing change, then update the affected sender with a documented rollback plan.
Keep the test small. Use a non-customer fixture with a unique reference and a known expected outcome. Confirm that every downstream node is safe for that fixture before triggering it; a diagnostic request can still send an email, create an invoice, or change a customer record.
Use an evidence map instead of random fixes
| Observed boundary | Next evidence to collect | Likely investigation owner |
|---|---|---|
| Sender has no delivery attempt | Event eligibility and sender configuration | Source-app owner |
| Endpoint request fails, with no execution | Exact route, method, published state, public network logs | Automation and hosting owners |
| Request is rejected by access checks | Authentication contract and approved caller identity | Integration/security owner |
| Execution exists but caller times out | Response path and elapsed processing stages | Workflow owner |
| Caller sees success but result is missing | Execution branches and target-app record evidence | Workflow and destination owners |
This is a diagnostic map, not a promise that a status code has only one cause. Compare the actual response body and logs with the system that produced them. A hosting intermediary and n8n can answer the same request differently.
Change one variable at a time. Save the initial observation, the proposed cause, the change, and the retest result. That record makes a successful repair explainable and prevents several speculative edits from becoming an undocumented production dependency.
For self-hosting, verify the public endpoint
If n8n is self-hosted, involve the person responsible for its network path. Compare the public address shown by the node with the address reachable by the sender. An internal container hostname or private port is not necessarily the public route.
The current reverse-proxy configuration guide documents a manually configured public webhook address and forwarded request headers. It currently names N8N_WEBHOOK_URL and notes deprecation of WEBHOOK_URL from version 2.35.0. Check the reference for your installed release rather than blindly replacing variables from an older deployment example. Proxy-hop configuration must reflect the actual trusted deployment topology.
Give the hosting owner a specific question: “Does this authorized request reach the expected application route?” Include the observation time and a redacted request reference. They can distinguish an upstream connection problem from application registration without needing every customer’s full payload.
Do not bypass certificate errors or open broad network access as a troubleshooting shortcut. If the public endpoint is incorrectly exposed, use the normal reviewed deployment process to correct it. A workflow that works only after protections are disabled is not an acceptable production repair.
Preserve authentication while diagnosing access failures
The Webhook credential reference describes Basic, Header, and JWT authentication. Establish the agreed authentication contract between the source and receiver, including which credential is configured and how the sender supplies it.
Compare names and configuration without exposing secret values. A support packet can state that the required header was present or absent, while storing the actual credential only in the approved secret-management system. Screenshots should hide values and customer data.
Check who is authorized to rotate or replace credentials. Avoid changing both ends simultaneously without a plan, because a partial rollout can create a new outage. Record the intended cutover and verify the authorized sender afterwards.
Authentication and request-signature verification are different design questions. Do not assume that selecting a generic credential automatically implements a particular provider’s signing scheme. Where that provider requires signatures, follow its official contract and use a reviewed implementation rather than improvised hashing.
If execution exists, inspect the response path
The Webhook node reference offers immediate responses, responses after the last node, and responses through a Respond to Webhook node. These choices change when the sender receives an answer. The reference also documents optional request filters; a current Only Run If condition that evaluates false can return 200 without creating an execution. Check feature availability in your installed version.
Write the sender’s expected acknowledgement beside the actual response. Does it need a particular status, body, or verification value? Do not treat any successful-looking response as equivalent to the provider’s documented contract.
The Respond to Webhook documentation explains that a workflow ending without executing that response node returns a standard 200 message; an error before the first response returns an error with status 500. Later response nodes do not provide an additional response to the same request.
Trace the relevant branch with the controlled fixture. If an early condition diverts the event away from the intended response, decide whether that branch should reject, acknowledge, or deliberately ignore the event. Document the business rule before adjusting the graph.
Separate acknowledgement from completed business work
A quick acknowledgement may be appropriate for an asynchronous design, but it should have a precise meaning. “Accepted for processing” is not the same as “the customer record is safely stored.” Make that distinction visible in your operating instructions.
For an illustrative document-processing workflow, a source may need an early acknowledgement while extraction and review continue later. Define a durable job reference and a way to observe the eventual result. If the workflow fails after acknowledgement, someone still needs responsibility for recovery.
Do not simply move the response earlier to conceal slow or failing work. First decide how events are preserved, how failures are surfaced, and how the source or operator obtains completion status. Otherwise, the timeout disappears while lost work becomes harder to detect.
Likewise, avoid replaying every delivery while the cause is uncertain. Check whether the target already received a record or message. An event that timed out at the sender may still have caused a downstream action, so recovery must account for possible duplicates.
A controlled recovery example
Imagine a consultancy whose website enquiry form previously passed development checks. The live source now reports delivery errors. The operator chooses one synthetic enquiry, records its reference, and compares the configured destination with the published node’s production address.
After correcting the agreed destination, the team sends that fixture once. They locate the corresponding execution, confirm the intended branch, and check the destination CRM for the fixture reference. They separately confirm that the source received the expected acknowledgement.
Before releasing the repair, they inspect the incident window for enquiries that may have been partially processed. Only verified missing events enter the recovery queue. Events with uncertain outcomes are reviewed rather than automatically duplicated.
This scenario illustrates an operating method, not a tested claim about a specific form provider. Adapt it to your service’s documented retry and delivery behavior. For broader platform trade-offs, use Daily Jade’s n8n versus Zapier comparison; switching platforms is a separate decision from fixing this incident.
Build a useful escalation packet
Include the n8n version, Cloud or self-hosted deployment type, workflow identifier, publication state, node method, redacted destination, event reference, observation times, sender response, and relevant execution result. State what you expected and where the evidence stops.
Explain the controlled changes already made. A hosting engineer should not have to discover that the URL, authentication, and response mode all changed during the investigation. Keep secret values out of the packet and share customer payloads only through an authorized support channel when necessary.
Assign an owner to the endpoint contract, not just the current editor. Daily Jade’s recurring-task automation guide can help establish ownership and operational checks. Use the business workflow automation guide when deciding where human approval belongs in a larger process.
Frequently asked questions
Why does the test URL work but the live integration fail?
Check whether the live sender uses the intended production destination and the correct published workflow. A manual test listener is temporary. Also compare the source’s actual method and authentication with your controlled test; two requests that look similar may exercise different paths.
Does an HTTP 200 prove the automation completed?
No. Determine what your response mode promises, then verify the execution and destination result. Some designs acknowledge receipt before downstream work completes. Current node filtering and response behavior can also produce success responses without the business outcome you expected.
Should I remove authentication to isolate the problem?
Not on a live endpoint. Compare the approved credential contract and use an authorized test request. If a separate test environment is needed, have its owner establish it through the normal security process rather than exposing production business actions to unknown callers.
Restore the contract, then monitor the outcome
To fix an n8n webhook that is not working, locate the failed boundary before changing the workflow. Match the destination and method, establish published state, check access and public routing, then inspect execution and response behavior. Finish with one traceable end-to-end event and a reviewed recovery queue. Keep evidence of both acknowledgement and the intended business result.
Join the conversation
Share a useful perspective, question, or first-hand experience with other Daily Jade readers.