Trigger Nodes (Slack & Telegram) unreliable in production (cloud version)

[mennovdmm]

Bug Description

Issue:
I'm experiencing consistent reliability issues with both Slack and Telegram trigger nodes in production.

Critical Observations:

• No executions appear in execution logs during production runs
• Only test executions are visible in logs
• When pressing "Test" button, previous (missed) messages suddenly execute
• This confirms messages are received but not processed in production

Details:

• Both Telegram and now Slack integrations are properly set up
• Both work perfectly in test mode
• In production, triggers are very inconsistent (mostly not working)
• No rate limits hit
• Webhooks and workflows are active
• Sometimes messages trigger the workflow, but most times they don't

Slack Setup:

• Events API configured
• Proper bot permissions/scopes
• Event verification working
• Channel selection working
• Test mode: Works 100%
• Production: Works ~20% of the time

Telegram Setup:

• Webhook configured
• Bot token set up correctly
• Test mode: Works 100%
• Production: Works ~20% of the time

What I've tried:

• Double checking all permissions
• Re-creating webhooks
• Different channels/chats
• Monitoring for rate limits
• Ensuring workflows are active

Key Issues:

1. Missing executions in production logs
2. No error messages or failures logged
3. Messages are received (proven by test button executing them later)
4. Production triggers seem to be "sleeping" until test is pressed

I've spent considerable time troubleshooting and even used ChatGPT/Perplexity AI to verify my setup, but the core issue remains: triggers are unreliable in production while working perfectly in test mode.

Questions:

1. Is this a known issue?
2. Are there any workarounds?
3. Would upgrading to a paid plan potentially fix this?
4. Why do messages only execute when pressing test?

I'm eager to use n8n for business purposes but need reliable trigger functionality first.

To Reproduce

Primary reproduction steps with Telegram (simpler to test):

1. Create new workflow
2. Add Telegram trigger node
3. Configure with:

• Bot token from @Botfather
• Select 'Message Received' as trigger

4. Add simple action node (e.g., Telegram 'Send Message')
5. Activate workflow

Expected behavior

Initial behavior:

• Webhook sets up correctly
• Test mode works perfectly
• Production executions work
• Messages appear in execution logs

After some time (usually within an hour):

• Triggers stop working in production
• No executions appear in logs
• No error messages
• Test button still works
• Pressing test button executes all missed messages
• Creating new workflow/node shows same pattern

Note: Same issue occurs with Slack integration, but Telegram setup is quicker for testing purposes.

Environment: n8n Cloud (free trial)

Key observations:

1. Always works in test mode
2. Production triggers always eventually stop
3. No error messages or logs
4. New workflows temporarily work, then stop
5. Missed messages are stored (proven by test button executing them)

Operating System

n8n Cloud (free trial)

n8n Version

n/a

Node.js Version

n/a

Database

SQLite (default)

Execution mode

main (default)

[Joffcom]

Hey @mennovdmm,

We have created an internal ticket to look into this which we will be tracking as "GHC-427"

[Joffcom]

Hey @mennovdmm,

One you activate the production url in Telegram are you then trying to use the test option as well? With Telegram and Slack are you also receiving a lot of messages at once?

---

Services like Telegram and Slack that only allow one webhook per app have issues when going between prod and test, Telegram is probably easier as it is automatic but Slack needs the urls to be manually changed.

Oddly one of the things we don't have the ability to do at the moment is cache webhooks so they can be sent later so I am not fully sure why they would then be sent once you test unless Telegram or Slack is trying to resend the values.

[mennovdmm]

Hi, Thank you for your clarifying response. I think I now understand what was happening, especially with the Slack setup. If I understand correctly: when running a test, n8n will always prioritize the test webhook URL over the production webhook, regardless of what URL is configured in N8N? This explains the confusion I experienced in my Slack setup. I initially moved from Telegram to Slack due to webhook reliability issues. However, the Slack problems turned out to be different in nature - they were related to this webhook URL precedence behavior rather than general reliability issues. After your explanation, I've reverted back to using the test webhook URL in Slack's Events API configuration (and whitelisted it), and now everything seems to be working as expected. This is quite different from my initial assumption that it was a general webhook reliability issue. It's good to understand that test and production webhooks can interfere with each other, especially for services like Slack that only allow one webhook URL at a time. Thanks for helping me understand this behavior - it has resolved my main issues with the Slack integration. Op 12 nov 2024, 16:09:29 schreef Jon ***@***.***>:

…

Hey @mennovdmm <https://github.com/mennovdmm>, One you activate the production url in Telegram are you then trying to use the test option as well? With Telegram and Slack are you also receiving a lot of messages at once? ------------------------------ Services like Telegram and Slack that only allow one webhook per app have issues when going between prod and test, Telegram is probably easier as it is automatic but Slack needs the urls to be manually changed. Oddly one of the things we don't have the ability to do at the moment is cache webhooks so they can be sent later so I am not fully sure why they would then be sent once you test unless Telegram or Slack is trying to resend the values. — Reply to this email directly, view it on GitHub <#11697 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BMSTIGCWNNHTSL5DXHYAVDD2AIK2TAVCNFSM6AAAAABRUC66QSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZQG44TAMZSHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>