Why this fails without throwing a visible error
Unlike a webhook verification failure, a missing event subscription does not produce an error in n8n at all — the workflow is active, the webhook URL is verified and saved, and n8n simply never receives a request because Slack never sends one for that event type or from that channel. This makes it look like an n8n bug when the gap is entirely on the Slack app configuration side.
Community threads describing this symptom consistently point to the Slack app's own Event Subscriptions page — specifically the list of Bot Events subscribed — as the place to check first, since a URL can be successfully verified while zero events are actually subscribed to it.
Check these events and scopes
| Event you want | Bot Event to subscribe | Required OAuth scope |
|---|
| New message in a public channel | message.channels | channels:history |
| New message in a private channel | message.groups | groups:history |
| Bot is @-mentioned | app_mention | app_mentions:read |
| Direct message to the bot | message.im | im:history |
| Reaction added to a message | reaction_added | reactions:read |
Fix and verify with a controlled test
After confirming the exact event type is subscribed and the app has been reinstalled (Slack requires reinstalling to the workspace any time Bot Token Scopes or subscribed events change — saving the Event Subscriptions page alone does not push the change live without this step), post a single test message in the watched channel from a different account than the one used to configure the app (self-generated events are sometimes excluded depending on event type and settings) and watch the n8n execution log for a new run.
If nothing appears, temporarily add a broader event (message.channels) as a control test — if that fires and the originally intended event still does not, the specific event type or its scope requirement is the remaining gap, not the overall pipeline.
Bot channel membership matters here too, exactly as with channel_not_found — a Trigger watching a channel the bot was never invited to will receive nothing, silently, for message-type events in that channel.
Self-hosted, queue-mode instances: a separate desync cause
If your n8n instance runs in queue mode (a main process plus separate worker processes, typically behind Redis), community reports describe schedule and trigger registrations silently failing to re-register after a restart, redeploy, or when the main and worker processes get out of sync. This is architecturally distinct from a Slack-app configuration gap — the trigger's registration inside n8n itself is the problem, not what Slack is sending.
If Slack-side configuration (events, scopes, reinstall, membership) all check out and the trigger still stays silent specifically after a recent restart or deploy, restart the main n8n process cleanly (not just the worker) to force triggers to re-register, and check n8n's own logs for registration errors at startup rather than only looking at the workflow execution list.
Sources checked for this guide
These reports describe the trigger-silent symptom independently across different n8n versions and hosting configurations.
Frequently asked questions
The webhook URL verified successfully — why is nothing still arriving?
Verification only proves the URL can respond to Slack's one-time challenge. It does not prove any actual event type is subscribed. Check the Bot Events list on Slack's Event Subscriptions page separately.
Do I need to reinstall the Slack app after adding a new event subscription?
Yes. Slack requires reinstalling (reauthorizing) the app to the workspace after changing subscribed events or bot scopes before the change takes effect for event delivery.
Could my own test messages be the reason nothing fires?
Possibly — some event configurations exclude events generated by the same bot or user used to test, depending on settings. Test with a message from a different account to rule this out.
This started right after I restarted my self-hosted n8n — is that related?
It can be, specifically on queue-mode deployments. Trigger registration can desync between the main process and workers after a restart or redeploy. Restart the main process cleanly and check its startup logs for registration errors.
