how to

n8n Test Webhook vs Production URL: Which One Should You Use?

Use the n8n test webhook URL only while the editor is listening for a short test event window; use the production webhook URL for real apps after the workflow is published or active.

Match your incident first

Start with the symptom you can prove

Jump to checks

Test URL works, production URL returns 404

First check: Open the Webhook node and compare the active production URL with the external app callback URL.

Wrong fix to avoid: Do not rebuild the whole workflow before proving whether the active production endpoint exists.

Verify: Activate the workflow, send a POST to the production URL, and confirm one new production execution appears.

Production URL shows localhost, container hostname, or http instead of public HTTPS

First check: Check the public URL shown in n8n and compare it with WEBHOOK_URL and reverse proxy forwarded headers.

Wrong fix to avoid: Do not paste the internal Docker service name into external SaaS callback settings.

Verify: The Webhook node displays the public HTTPS domain and an external curl reaches n8n without redirect loops.

External app times out but n8n logs show no execution

First check: Run an external curl smoke test and inspect reverse proxy access logs for the same timestamp.

Wrong fix to avoid: Do not rotate credentials when the request never reaches n8n.

Verify: Proxy access log and n8n execution log both show the same request.

Use when: n8n workflows, webhooks
First check: Confirm the workflow is active or published and the caller is using the production webhook URL.
Time to check: 5-10 minutes
Next step: Match the symptom, then run the verification checks.

Independent third-party notes. n8n is a trademark of its owner and is referenced only for compatibility and troubleshooting context.

Quick Answer

Use the n8n test webhook URL only while the editor is listening for a short test event window; use the production webhook URL for real apps after the workflow is published or active.

Does this match your symptom?

Webhook is not reaching production

A test webhook works in the editor, but the production URL returns 404, uses the wrong method, or never creates an execution.

First check: Confirm the workflow is active or published and the caller is using the production webhook URL.

Problem Pattern

The workflow works during manual editor testing but fails after the URL is pasted into a real third-party service.

Version awareness

Last reviewed 2026-06-05

Applies to: n8n Cloud when using webhooks, self-hosted n8n, Docker, reverse proxy, custom domains
Official docs checked: n8n Webhook Node, n8n Webhook workflow development, n8n Webhook common issues, n8n Configure webhook URLs with reverse proxy
Version-sensitive assumptions: n8n node parameters, credential names, and queue mode defaults can change between releases; confirm against your installed version before changing production.
What may change after upgrades: Node parameter names, credential scopes, webhook behavior, Docker image defaults, and queue worker expectations may shift after n8n upgrades.

Key Facts

Test URL: Designed for testing while the workflow is open and listening for a test event.
Production URL: Designed for published or active workflows and real integrations.
Common mistake: Pasting a test URL into a third-party production webhook configuration.
Activation: Production webhooks require the workflow to be published or active.

Production Diagnostic Matrix

Turn checks into a brief

Exact symptom or log	Likely cause	First check	Wrong fix to avoid	Verification
Test URL works, production URL returns 404	Workflow is not active, caller is using the test URL, or the production path was changed after activation.	Open the Webhook node and compare the active production URL with the external app callback URL.	Do not rebuild the whole workflow before proving whether the active production endpoint exists.	Activate the workflow, send a POST to the production URL, and confirm one new production execution appears.
Production URL shows localhost, container hostname, or http instead of public HTTPS	WEBHOOK_URL, N8N_HOST, N8N_PROTOCOL, or proxy headers do not match the public domain.	Check the public URL shown in n8n and compare it with WEBHOOK_URL and reverse proxy forwarded headers.	Do not paste the internal Docker service name into external SaaS callback settings.	The Webhook node displays the public HTTPS domain and an external curl reaches n8n without redirect loops.
External app times out but n8n logs show no execution	DNS, firewall, Cloudflare, reverse proxy, or path routing blocks the request before it reaches n8n.	Run an external curl smoke test and inspect reverse proxy access logs for the same timestamp.	Do not rotate credentials when the request never reaches n8n.	Proxy access log and n8n execution log both show the same request.
Workflow receives payload but caller gets wrong response or hangs	Respond to Webhook is missing, configured for the wrong response mode, or waits for a branch that does not finish.	Check the Webhook node response mode and the Respond to Webhook node path.	Do not add arbitrary Wait nodes to hide timeout behavior.	Caller receives the intended status code and body within the provider timeout window.
Webhook path works internally but fails through reverse proxy	Proxy location, base path, body size, TLS termination, or forwarded proto/host headers are wrong.	Compare direct container access with the public reverse proxy route and check forwarded headers.	Do not disable HTTPS verification as a proxy troubleshooting shortcut.	Public HTTPS request preserves method, path, body, and host all the way to n8n.

Still blocked after these checks?

Use the brief to decide whether to keep fixing this setup, move the workload to n8n Cloud, or rebuild the self-hosted path on cleaner infrastructure.

Compare tools

Recommended Steps

During workflow design, copy the test URL from the Webhook node.
Select Listen for test event, then trigger the test URL while the listener is open.
Once the workflow works, publish or activate it.
Copy the production URL and paste it into the external app.
Send one production request and verify the execution appears in execution history.

Verification

Test calls appear while the editor is listening for a test event.
Production calls appear in execution history after publication or activation.
The external app stores the production URL, not the test URL.

First Commands / Checks

Webhook smoke test Use when an external app reports timeout, 404, or wrong response.

curl -i -X POST https://automation.example.com/webhook/example-path \
  -H "content-type: application/json" \
  -d '{"smokeTest":true}'

Secrets note: Use a disposable path or non-sensitive payload. Do not paste provider signing secrets into curl examples.
Verification: The response status and body match the Webhook or Respond to Webhook configuration.

Check container state Use first when n8n is down, restarting, or behaving differently after a deploy.

docker compose ps

Secrets note: This lists service names and status only; it should not print credential values.
Verification: n8n, database, Redis, and worker services are running or the failing service is obvious.

Read recent n8n logs Use when the editor, webhook, or startup path fails.

docker compose logs n8n --tail=100

Secrets note: Review before sharing; remove tokens, private hostnames, and customer payloads.
Verification: The log contains a timestamped error, migration message, or clean startup line.

Check public URL variables only Use when webhook URLs show localhost, http, or the wrong domain.

docker compose exec n8n printenv WEBHOOK_URL N8N_HOST N8N_PROTOCOL N8N_EDITOR_BASE_URL

Secrets note: Do not run a full env dump in public channels; print only these non-secret routing names.
Verification: Values point to the intended HTTPS public domain.

Warnings

Do not use test URLs for real production integrations.
The test listener is temporary; a saved test URL can fail later even when the workflow is correct.
If a production webhook does nothing, check workflow publication or activation first.
Production webhook payloads are verified from execution history, not from the editor's test waiting state.

Best For

Users confused by the two URLs shown in the Webhook node.
Workflows that pass editor tests but do not run from a live app.
Teams preparing to move a webhook workflow from development to production.

Not For

Non-webhook trigger nodes.
Outgoing API requests from the HTTP Request node.
Cases where the workflow should intentionally stay manual-only.

Common Mistakes

Saving the test URL in Stripe, Typeform, GitHub, or another external app.
Expecting a production webhook to work while the workflow is not published or active.
Looking for production webhook payloads in the editor's test listener instead of execution history.
Changing the webhook path after a third-party app already stores the old URL.
Testing only in the editor and never making an external production request.

Examples

URL selection rule Use this as the simple decision tree.

Building the workflow in the editor? Use the test URL after selecting Listen for test event.
Connecting a real third-party app? Publish or activate the workflow and use the production URL.
Changed the path or domain? Update the third-party app.

Production handoff checklist Run this before handing the URL to another tool.

Workflow published or active: yes
Production URL copied: yes
Public domain correct: yes
HTTPS valid: yes
External smoke test received: yes
Execution history checked: yes

Mode mismatch clues Use these clues before changing node logic or credentials.

Works only during Listen for test event -> caller is using the test URL
Works from curl but not provider -> compare stored URL, method, headers, and auth
Execution exists but editor stays empty -> production run is in execution history
Generated URL uses localhost -> fix WEBHOOK_URL or reverse proxy settings

404 triage for production webhooks Use this when a third-party service says the URL is not found.

404 only on test URL -> editor is not listening or the wrong mode is being used
404 on production URL -> check workflow publication or active status, method, path, and public domain
Works in browser but not provider -> compare HTTP method, headers, auth, and stored URL
Works before domain change -> update the provider webhook URL

External app smoke test A real production test should create an execution, not just load a page.

Send one request from the actual external app
Confirm status code is expected
Open n8n execution history
Verify the run is a production execution
Confirm payload fields match the downstream nodes

FAQ

Can I use a test webhook for production?

No. Test URLs are for development while the editor is listening for a test event. Production integrations should use the production URL on a published or active workflow.

Does activating a workflow change the URL?

The Webhook node exposes a production URL intended for active workflows. Always copy the production URL after the workflow path and public domain are final.

Why did a third-party app keep calling the old URL?

External apps store the URL you give them. If you change path, domain, or test versus production mode, update that app's webhook settings.

Sources

n8n Webhook Node Accessed 2026-06-05 n8n Webhook workflow development Accessed 2026-06-05 n8n Webhook common issues Accessed 2026-06-05 n8n Configure webhook URLs with reverse proxy Accessed 2026-06-05