Trigger webhooks cleared on n8n version update

Describe the problem

Every time we update our n8n cloud instance the trigger webhooks get completely removed. In our case these are Zendesk triggers.
After updating the n8n workflows still have the published green dot even though there is no triggers on the Zendesk side so the workflows are non functional. In this case you have to update the workflow, to be able to republish it, after doing that the webhooks appear in the Zendesk admin panel, and the workflows are functional again.

n8n cloud version: Version 2.17.6
After updating


After re-publishing

1 Like

Familiar pattern — webhook registrations getting lost on upgrade is a known pain point with any update that touches the webhook engine. Re-publishing is the right workaround, just annoying to do manually across many workflows.

Worth raising with n8n support ([email protected]) so they track it — ideally the upgrade process should re-register active webhooks automatically.

Had the exact same issue on self-hosted — webhook registrations silently disappearing after updates/patches while the workflow still shows as “Published” with the green dot.

The root cause is that n8n maintains two separate states for a workflow: the draft (what the editor shows) and the published version (what the webhook engine actually uses). When n8n restarts after an update, it re-registers webhooks from the published version — but if the published version got out of sync, the webhooks vanish.

What we found works reliably:

  1. Toggle the workflow off and back on. This forces n8n to re-register all webhooks from the current published version. On self-hosted you can automate this via the REST API:

  2. 
    POST /rest/workflows/{id}/deactivate
    
  3. POST /rest/workflows/{id}/activate

  4. 
    (The activate endpoint needs `{"versionId": ...}` in the body — get it from `GET /rest/workflows/{id}`.)
    
  5. If you manage workflows via API (PATCH): be aware that PATCH /api/v1/workflows/{id} only updates the draft, NOT the published version. You still need to publish through the UI or use the deactivate/activate cycle above to sync the webhook handler.

  6. After any n8n update, we now run a quick script that deactivates and reactivates all active workflows as a post-upgrade step. Takes seconds, prevents exactly this problem.

For n8n cloud, the equivalent is just toggling each affected workflow inactive → active from the UI, which Benjamin’s suggestion of re-publishing also achieves.

Would be great if the upgrade process handled this automatically — @Benjamin_Behrens is right that it’s worth raising with support.

That’s a good idea! Regardless if you’re using cloud or self hosted you can still do that via API, I’ll try setting it

1 Like

good day @terraxus
I’d also recommend checking the Executions / webhook logs right after the upgrade to see whether n8n attempted to re-register the Zendesk webhooks and received an error from Zendesk. If the registration call is failing silently due to permissions, rate limits, or API changes, that would explain why the workflow still looks published but the external trigger is missing.

AFAIK Zendesk doesn’t have any logging on their end, is this available on n8n’s side aside from executions? In my error flow I only see this after updating

Should I assume that’s n8n trying to re-register the webhook on Zendesk’s end?

I wouldn’t assume it with certainty, but the screenshots strongly suggest it…
try get the exact request context from n8n support, because normal executions won’t show the full trigger-registration call. I’d share the timestamp, workflow ID, Zendesk trigger type, and the before/after screenshots with support so they can check backend logs for the failed registration attempt.