I’ve noticed an issue with the Telegram trigger. It seems that the trigger doesn’t immediately pick up new messages. Instead, there is a noticeable delay before it reacts—as if it “falls asleep.” After the first message is received, everything works normally.
However, if the bot doesn’t receive messages for a short period, the delay returns, and the trigger again responds with a lag.
Has anyone experienced this behavior or found a way to prevent the trigger from “going to sleep”? Any advice would be appreciated!
“ Try use “Polling” mode instead of Webhook. If you can switch to a polling approach, try using the Telegram > Get Updates method (manually via HTTP Request node or custom polling) instead of relying on the webhook. Polling doesn’t rely on webhooks staying alive and is often more reliable for long-running bots on hosted environments like n8n Cloud.
Also, sometimes, n8n-hosted workflows get paused due to inactivity or platform constraints. Set up a second Cron workflow that hits the Telegram Trigger workflow via an HTTP request (using n8n’s webhook URL) every few hours. This keeps it “awake” and helps prevent disconnects.
Hi @oduvanekb Welcome!
I felt that kind of issue with telegram & slack, what i have done is EXECUTIONS_PROCESS=main in my env variable, so that all my flows production executions run in the main process eliminating that sleep behavior or a slight delay, it is worth giving a try. See this:
Both fixes are valid — which one applies depends on your setup.
Self-hosted:EXECUTIONS_PROCESS=main (as @Anshul_Namdev mentioned) removes the inter-process handoff that causes the lag. Had a similar delay with a Slack trigger once, this env var sorted it out.
n8n Cloud: Polling via Telegram > Get Updates + a keep-alive Cron (as @Ectilow suggests) is the more reliable combo. Cloud instances can pause during inactivity, and polling sidesteps the webhook sleeping issue entirely.
One more thing worth checking: the webhook timeout. n8n Cloud defaults to 5 minutes — if any step in your workflow takes longer, the trigger can appear to “miss” messages. You can adjust it under Settings > Executions timeout.
It usually happens when the trigger/webhook becomes idle for a while, so the first new message is a bit delayed, then the next ones work normally again.
A few things to check:
Make sure your n8n instance is always running and not going idle
Reconnect the Telegram credentials / webhook once
Check whether your hosting platform is putting the app to sleep
If you are on cloud/self-hosted behind a proxy, make sure the webhook is stable and publicly reachable
So this may not be a Telegram problem itself, but more likely an idle/sleep or webhook delay issue in the n8n setup.
One pattern that helps regardless of setup
add a scheduled canary message.
Set up a Cron that sends your bot a test message
every 30 minutes. If the trigger is alive,
it processes silently. If it’s gone idle,
the first canary wakes it up before a real user hits it.
Poor man’s uptime check, but works surprisingly well.
[UPDATE] Telegram Webhook Issue Evolved - Now Getting DNS Resolution Error
Update to Previous Issue:
This is a continuation of an ongoing Telegram integration problem. Initially had different errors, but after troubleshooting (including regenerating bot token), the issue has evolved into a more specific DNS-related problem.
Current Situation:
Unable to activate ANY Telegram workflows. All bots affected simultaneously. Getting consistent error when trying to publish/activate workflows:
Bad Request: bad webhook: Failed to resolve host: Temporary failure in name resolution
CRITICAL OBSERVATION:
Workflows with Telegram Trigger that are ALREADY published/active → WORK FINE
If I deactivate them → CANNOT re-activate/publish
Workflows WITHOUT Telegram Trigger → publish/unpublish without any issues
Problem is ONLY with Telegram Trigger activation/registration process
Environment:
n8n version: 2.16.1 (upgraded from 2.15.0 - same problem in both versions)
Running in Docker (docker-compose)
Self-hosted on a .ru domain
HTTPS with valid SSL certificate
All environment variables properly configured (WEBHOOK_URL, N8N_HOST, N8N_PROTOCOL)
Timeline:
Everything was working fine ~1 hour ago
Problem started suddenly across ALL Telegram bots
Regenerated Telegram bot token → didn’t help
Restarted n8n containers → didn’t help
Upgraded from n8n 2.15.0 to 2.16.1 → didn’t help
What We’ve Verified: DNS resolution works INSIDE n8n container (docker exec + nslookup resolves domain correctly to IP) Domain is publicly accessible from external networks SSL certificate is valid (curl -I shows 200 OK) All environment variables correctly set in both docker-compose.yml and .env file n8n generates correct webhook URLs Webhook endpoint accessible (returns expected 404 when workflow inactive) Non-Telegram workflows publish/unpublish normally Already-active Telegram workflows continue to work
The Paradox:
n8n container CAN resolve the domain
External browsers CAN access the domain
Already-registered Telegram webhooks WORK
NEW Telegram webhook registration FAILS (Telegram servers claim DNS error)
Additional Testing:
Manually calling Telegram API’s setWebhook → same DNS error
Calling getWebhookInfo → webhook URL field is empty
Why would existing webhooks work but new registrations fail?
Is there a way to use Telegram Trigger in polling mode instead of webhooks?
Any known workarounds when Telegram cannot reach webhook URL due to DNS issues on THEIR side?
Has anyone experienced similar issues with .ru domains or regional restrictions?
Could this be related to Telegram API changes or regional blocking?
This additional information is crucial - it suggests the problem is specifically with Telegram’s webhook registration process, not with the webhooks themselves once registered!
The issues persist: I even deployed a clean n8n instance on a different IP and domain and updated to the latest version, but the problem remains. When trying to register a Telegram Trigger webhook, Telegram returns errors like “Failed to resolve host” or “Connection timed out,” even though the domain resolves correctly, SSL is valid, and the endpoint is accessible via browser and curl; at the same time, my previously published workflows with Telegram Triggers continue to work fine, while any new or reconfigured trigger fails to set the webhook. Could this be related to how n8n registers webhooks or external connectivity issues, and is the Telegram Trigger currently working normally on your side?
This is almost certainly a Telegram infrastructure issue with .ru domains, not an n8n configuration problem. Your diagnosis is correct the paradox (existing webhooks work, new registrations fail) is the key tell.
Here’s what’s happening: when you register a new webhook, Telegram’s servers make an outbound DNS lookup to validate your endpoint before confirming registration. Their infrastructure appears to be blocking or failing to resolve .ru TLDs at the registration step — but already-registered webhooks bypass this check entirely since the URL is already stored on their side.
The cleanest workaround right now:
Set up a Cloudflare Tunnel (free) in front of your n8n instance. This gives you a *.trycloudflare.com or custom domain URL that Telegram’s servers have no problem resolving. Point your WEBHOOK_URL to the Cloudflare Tunnel URL, keep n8n running on your .ru domain internally.
Alternative — polling mode: n8n’s Telegram Trigger doesn’t have native polling, but you can replicate it: use a Schedule Trigger (every 30s) + HTTP Request node calling https://api.telegram.org/bot{TOKEN}/getUpdates?offset={last_update_id}. Store the offset in a variable or simple database. Not as clean as webhooks but completely bypasses the registration issue.
Do not regenerate the bot token again — that won’t help and invalidates your working webhooks.
The fact that your already-active workflows keep working means your infrastructure is fine. This is 100% on Telegram’s side with .ru resolution during the setWebhook call.
I also tried using a Cloudflare Tunnel as a workaround to bypass potential network restrictions: the domain was routed through the tunnel, DNS resolved correctly to the Cloudflare endpoint, and the n8n instance was accessible externally via HTTPS. There was one successful execution where the webhook appeared to trigger, but it didn’t receive or process any updates, and shortly after that the same errors (“Failed to resolve host” / “Connection timed out”) started appearing again when trying to register or use the webhook. I’ll try everything once again from scratch and see if I can reproduce or isolate the issue more clearly. Thanks a lot for your help — really appreciate it.
That one successful execution is actually useful data — it confirms the webhook URL itself is valid and reachable. The fact that it fired once and then stopped suggests Telegram’s servers are intermittently blacklisting or rate-limiting new webhook registrations from your IP range, not just failing DNS.
Two things worth trying before starting from scratch:
Switch to polling workaround. In n8n, replace the Telegram Trigger with a Schedule node (every 30 seconds) + HTTP Request to https://api.telegram.org/bot{TOKEN}/getUpdates?offset=-1&limit=10. This completely bypasses webhook registration — Telegram never needs to reach your server, your server polls theirs. Not elegant but it works regardless of what Telegram does with .ru domains.
Test with a fresh bot token on a completely different domain (not .ru). If registration succeeds immediately, you’ve confirmed it’s a .ru-specific block on Telegram’s end, not your infrastructure.
The Cloudflare Tunnel result suggests the problem isn’t your DNS at all it’s Telegram’s outbound connection to your region being unstable. The polling approach sidesteps that entirely.
I also deployed a fresh n8n instance on a .tech domain to rule out any issues specific to .ru, but I’m seeing exactly the same behavior: existing Telegram Trigger webhooks continue to work, while any new webhook registration fails with “Failed to resolve host” or “Connection timed out,” even though DNS, SSL, and endpoint accessibility are all confirmed to be working.
That’s a very elegant workaround — thanks, I’ll try using it for now. Still, it’s not entirely clear what’s going on with the Telegram Trigger and why this started happening so suddenly.
The .tech test is actually the most useful data point in this whole thread. It rules out domain-specific blocking entirely. The problem is definitively on Telegram’s side their webhook registration servers are experiencing an outage or connectivity issue that affects new registrations globally, not just .ru.
The “why so suddenly” part: Telegram occasionally has infrastructure incidents where their webhook registration endpoint becomes unreliable while already-registered webhooks continue working fine. This happens because registration and delivery use different server paths. It’s not documented anywhere officially, which is why it’s so confusing to diagnose.
The polling workaround will hold you over. When Telegram’s registration service recovers you’ll be able to switch back — just activate a workflow with a Telegram Trigger and it should register cleanly. Worth checking the Telegram Status page and the n8n community forum in a day or two to see if others report the same issue resolving.
