Prod: n8n WhatsApp Trigger Not Working (Workflow Published)
Describe the problem/error/question
The production n8n WhatsApp Trigger stopped working today (21 April 2026). The workflow was published, but when a user sent a message, the trigger did not fire.
As a workaround, unpublishing and then republishing the production workflow made the WhatsApp Trigger work again. However, needing to unpublish/republish to restore the trigger is not ideal.
Does anyone know why this happens, or what could be causing the trigger to stop firing?
What is the error message (if any)?
Please share your workflow
Share the output returned by the last node
No output was returned because the node was not being triggered when a user sent a message.
@damjeff the webhook registration goes stale on Meta’s side, republishing just forces a re-register. set up a watchdog workflow that re-activates your whatsapp workflow on a schedule so the webhook stays fresh
swap YOUR_WORKFLOW_ID for the actual id of your whatsapp workflow, set up an n8n API key under Settings → API and use that as the header auth credential with header name X-N8N-API-KEY.
@damjeff this is a known issue — the WhatsApp Cloud API webhook registration goes stale on Meta’s side. As @achamm mentioned, a watchdog workflow is the right fix. Here’s what I run in production:
The watchdog pattern:
A separate workflow on a cron schedule (I use every 6 hours) that calls n8n’s own API to deactivate then re-activate your WhatsApp workflow. The two endpoints you need:
POST /rest/workflows/{id}/deactivate
POST /rest/workflows/{id}/activate
The activate call requires {“versionId”: “…”} in the body — get the current versionId from GET /api/v1/workflows/{id}.
Set up a Header Auth credential with your n8n API key (Settings > API > Add API Key) using header name X-N8N-API-KEY.
Why this works: deactivate + activate forces n8n to re-register the webhook with Meta, which is exactly what unpublishing/republishing does manually. Running it on a schedule means the webhook never stays stale long enough to miss messages.
Bonus — detect it before your users notice:
I also run a monitoring workflow on a 30-min cron that queries GET /rest/executions?status=error&limit=10, filters for my WhatsApp workflow ID, and sends me a notification if there are errors within the last 35 minutes (the overlap avoids re-alerting). This way I know about problems before customers complain.
Been running WhatsApp bots for local businesses in production for months — this pattern has been rock solid.
Hello. I tried your suggestion.
I added the ID and the API key.
However, when running the node, I am getting the error in screenshot.
Any idea how to resolve it please?
Separate two checks here: whether n8n’s own API can read that workflow, and whether Meta’s WhatsApp webhook is registered after activation.
Start with a plain GET to your n8n API for that workflow ID. If it returns 401 or 403, the issue is usually API auth/base URL for that instance. If it returns 404, the ID is probably not the production workflow. If it times out or gives 5xx, check the public instance URL/reverse proxy before touching the WhatsApp node.
Once that GET returns the workflow JSON, run the deactivate/activate calls manually once and then turn them into the watchdog. The smallest useful detail to post back here is the HTTP status plus the error text from the failing HTTP node.
