(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
Welcome @Davycrockettzoo_The
Can you share more informations about your webhook issue?
Two main points about production webhooks:
More details here: Webhook node documentation | n8n Docs
: *“All production webhooks return 404 on instance davycrockettzoo.app.n8n.cloud despite workflows being active. Test URLs work. Tried restart, re-save, path changes — nothing fixes it. Likely tenant-level webhook routing failure.”
This what I get back:* Why It Happens
This is a known bug in n8n Cloud (GitHub issues #22782, #25576, #21614). The root cause is at the tenant/infrastructure level — the routing layer that maps webhook paths to your specific instance container is broken. It’s not about:
Your workflow config (correct — test URL proves it)
Your webhook path (we tried multiple)
Your trigger type (we tried Webhook, Chat Trigger, etc.)
How the workflow was created (API vs UI — both fail)
Only n8n’s infrastructure team can fix this. They need to reset or rebuild the webhook routing table for your tenant (davycrockettzoo). No amount of toggling, restarting, or recreating workflows on our end will fix it — the bug is upstream of all that.
Hey @Davycrockettzoo_The,
Welcome to the community,
I checked this based on what you mentioned, and yes: there are recent reports that match what you’re seeing on n8n Cloud (prod webhooks 404 even though workflows are active), including GitHub issues like #22782 and #25576 where the troubleshooting ruled out workflow config and pointed to a workspace/tenant routing/registration problem that needs infra-side intervention.
That said, it’s still worth doing the 2 quick sanity checks first because they cause the same symptom: make sure the external service is calling the production URL (/webhook/…, not /webhook-test/…) and confirm the workflow is actually Active (test URLs only work while “listening” in the editor, otherwise they 404). n8n’s own webhook “common issues” docs cover this exact trap.
If you’ve already confirmed those basics and every production webhook on davycrockettzoo.app.n8n.cloud returns 404 across multiple new minimal workflows, then your conclusion is reasonable: this looks like the same “tenant-level routing/registration broken” class of issue, and the fix is on n8n Cloud’s side (reset/rebuild webhook routing/registration for the workspace). At that point the best next step is opening a Cloud support ticket and sending: workspace URL, 2–3 example workflow IDs, 2–3 production webhook URLs returning 404, and confirmation that fresh minimal webhooks also fail.
One extra detail: issue #21614 is specifically about webhooks not registering when workflows are deployed/activated via API, so if you’re provisioning workflows programmatically, mention that too in the ticket.
Thank you so much!
One extra detail: issue #21614 is specifically about webhooks not registering when workflows are deployed/activated via API, so if you’re provisioning workflows programmatically, mention that too in the ticket - This is a good one - I deploying it via a local host - and I did the 2 quick sanity checks!
Welcome, thanks for confirming, If you’re deploying from localhost / provisioning programmatically and you’ve already done the sanity checks (active workflow + hitting the production /webhook/… URL), then this still points to a registration/routing issue on the Cloud side rather than anything in your workflow.
Did the support ticket / reset help yet?