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.
你好。我試過你的建議。
我添加了 ID 和 API 密鑰。
但是當運行節點時，我收到了屏幕截圖中的錯誤。
請問有什麼辦法可以解決嗎？
在這裡分開檢查兩項：n8n 自身的 API 是否能讀取該工作流程，以及 Meta 的 WhatsApp webhook 在啟動後是否已註冊。
首先對該工作流程 ID 向你的 n8n API 發送簡單的 GET 請求。如果返回 401 或 403，問題通常是該實例的 API 身份驗證/基礎 URL。如果返回 404，ID 可能不是生產工作流程。如果超時或返回 5xx，在觸碰 WhatsApp 節點之前，先檢查公開實例 URL/反向代理。
一旦該 GET 返回工作流程 JSON，手動執行一次停用/啟用呼叫，然後將其轉為看門狗。最小有用的詳細資訊是 HTTP 狀態碼加上失敗 HTTP 節點的錯誤文本。
我遇到了同樣的問題，你有找到解決方案嗎？如果有的話，請告訴我一下
