How to Fix n8n Telegram Trigger Not Working: A 6-Step Diagnostic Checklist

Introduction

The Telegram Trigger node is the most common way to let a Telegram bot start an n8n workflow, and it is also one of the most complained-about nodes in the n8n community forum. The typical story: you create a bot with BotFather, paste the token into n8n, click Execute step on the node, send a test message, watch the green checkmark appear, and celebrate. Then you close the editor, go live, and nothing ever fires again. Or worse: it worked yesterday and went silent overnight with no change on your side. This checklist is aimed at anyone running n8n Cloud or a self-hosted n8n in Docker. Every diagnostic command below calls Telegram’s public Bot API directly, so you read ground truth from Telegram’s side instead of guessing.

Quick answer

Most Telegram Trigger failures need three checks: the workflow is active or you are listening on the test URL, getWebhookInfo shows n8n’s URL with no error, and no other app shares the bot token.

Evidence

The scale of the problem follows the scale of the two platforms. A live GitHub API check on 2026-10-20 showed the n8n-io/n8n repository at 208,070 stars, making it one of the most widely self-hosted automation tools in existence. On the Telegram side, Pavel Durov announced in March 2025 that Telegram had crossed 1 billion monthly active users, which is why bots keep showing up in automation workflows despite the rough edges.

Those rough edges are documented by both vendors. n8n’s Telegram Trigger documentation lists more than twenty trigger events and warns that some events require additional permissions, such as making the bot a group admin, and that the default * event deliberately excludes Chat Member, Message Reaction, and Message Reaction Count updates. On webhook mechanics, Telegram’s Bot API documentation is blunt: “You will not be able to receive updates using getUpdates for as long as an outgoing webhook is set up,” which is the single-consumer rule behind Step 3. And n8n’s own reverse-proxy guidance names the self-hosting trap behind Step 5:

“n8n creates the webhook URL by combining N8N_PROTOCOL, N8N_HOST and N8N_PORT. If n8n runs behind a reverse proxy, that won’t work. That’s because n8n runs internally on port 5678 but the reverse proxy exposes it to the web on port 443.”

The same diagnostic is what the community itself converged on: a 2026 n8n forum thread (community.n8n.io/t/302306) resolved a dead trigger by reading getWebhookInfo and interpreting last_error_message and pending_update_count, the approach in Step 1.

Prerequisites

• A Telegram bot token from BotFather, kept in a shell variable (BOT_TOKEN) rather than pasted into screenshots or logs.
• n8n Cloud, or a self-hosted n8n (Docker Compose is the typical setup; our Docker Compose setup guide for n8n covers it).
• curl and python3 (for pretty-printing JSON) on your machine.
• Admin access to the n8n editor so you can activate workflows and edit environment variables.

Step-by-step guide

Step 1: Ask Telegram what it thinks, with getWebhookInfo

The Telegram Trigger is a webhook node. When it starts listening, n8n calls Telegram’s setWebhook with an n8n URL, and from then on Telegram POSTs every update to that URL. If nothing fires, the first question is never “what is wrong with n8n” but “what does Telegram believe about this bot”. The getWebhookInfo method answers exactly that:

curl -s "https://api.telegram.org/bot${BOT_TOKEN}/getWebhookInfo" | python3 -m json.tool

A healthy registration looks like this:

{
    "ok": true,
    "result": {
        "url": "https://n8n.example.com/webhook/9f3a2c1d-…/telegram",
        "has_custom_certificate": false,
        "pending_update_count": 0,
        "max_connections": 40
    }
}

Read the three fields that matter. url is empty means no webhook is registered: the workflow is inactive and you are not listening on a test URL, the token was regenerated, or registration failed (Step 2). last_error_message is present means Telegram tried to deliver and failed, in plain language: "Wrong response from the webhook: 404 Not Found" points at a wrong path or inactive workflow, "Connection timed out" at an unreachable n8n, an SSL-flavored error at certificate trouble. This field is the fastest diagnosis you have, so always read it before changing anything. pending_update_count is large and growing means Telegram is queueing undeliverable updates; fix delivery first, then clear the backlog with deleteWebhook (Step 3).

Step 2: Confirm you are on the right URL, test or production

n8n webhook triggers, including the Telegram Trigger, have two lives, and mixing them up is the number one cause of “it worked once and stopped”:

• Test URL (/webhook-test/...): registered when you click Execute step (or “Listen for test event”) on the node. It lives only while the editor is listening. Send your Telegram message during that window and the run appears on the canvas. Close the tab or stop listening and the trigger dies with it.
• Production URL (/webhook/...): registered when the workflow is active (the toggle in the top-right of the editor). It stays alive as long as the workflow stays active. Production executions do not appear on the canvas; they show up in the Executions tab.

So the check is mechanical: if getWebhookInfo shows a URL containing webhook-test, you are looking at a leftover test registration. Either click Execute step on the node again and send your test message inside the listening window, or activate the workflow for real operation and re-check that the registered URL switched to the production form.

Deactivating a workflow removes its webhook registration, so if your trigger went silent right after you toggled the workflow off and on, this is why. Re-activate, wait a few seconds, and re-run Step 1 to confirm the URL is back.

For the general test-versus-production behavior, including the exact 404 variants n8n returns when you call the wrong one, see our guide to fixing n8n’s webhook-not-registered 404 errors.

Step 3: Enforce one bot, one consumer

Telegram delivers each bot’s updates to exactly one webhook URL, with no fan-out and no warning when a second registration steals delivery. The usual thieves:

• A second n8n workflow using the same bot token (for example, an old experiment you forgot to delete).
• A second n8n instance (staging vs production) sharing credentials.
• A dev script, a Python bot, or a bot platform you tried months ago that called setWebhook once and was never cleaned up.

The symptom is distinctive: the workflow is active, the URL is correct, getWebhookInfo shows no error, pending_update_count stays at 0, and still nothing fires, because Telegram is happily delivering every update to someone else’s URL. Compare the url from Step 1 against the Production URL in your Telegram Trigger node’s panel. If they differ, you found the thief.

Reclaim the token with deleteWebhook, passing drop_pending_updates=true so the stale queue does not flood you with ancient messages the moment you re-register:

curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/deleteWebhook" \
  -d "drop_pending_updates=true"

Confirm {"ok":true,"result":true}, then activate your n8n workflow (or click Execute step for a test) and re-run Step 1. The URL should now be n8n’s, and only n8n’s. Going forward, treat a bot token like a password: one token, one consumer. If two workflows need the same bot, keep a single Telegram Trigger workflow and route inside n8n with Switch or Execute Workflow nodes.

Step 4: Fix BotFather privacy mode and admin rights

If the trigger fires for direct messages to the bot but stays silent in a group or channel, the webhook is fine and Telegram’s delivery is fine. The bot is simply not allowed to see those messages.

In groups, bots created via BotFather have privacy mode enabled by default. A privacy-mode bot only receives commands (messages starting with /), replies to its own messages, and mentions of its username. Regular group chatter never reaches it, so your trigger never fires. Check the current setting with getMe, which reports can_read_all_group_messages: true when privacy mode is disabled:

curl -s "https://api.telegram.org/bot${BOT_TOKEN}/getMe" | python3 -c \
  "import json,sys; print(json.load(sys.stdin)['result'].get('can_read_all_group_messages'))"

If it prints False or None, open a chat with BotFather, send /setprivacy, pick your bot, and choose Disable. This is the single most common fix for “works in DM, dead in group”. Two related permission traps, both documented in n8n’s Telegram Trigger event list:

• Some events need the bot to be a group admin: Chat Member updates, Chat Join Requests (which additionally need the can_invite_users right), Message Reactions, and Chat Boosts. If your trigger listens for one of these and the bot is a plain member, nothing arrives.
• For channels, the bot must be added as an administrator with post rights to receive Channel Post updates. Merely joining the channel is not enough.

Also verify the obvious: the bot was actually added to the group or channel you are testing in. A bot cannot receive updates from a chat it is not a member of (except the newer guest-mode flows, which the standard trigger does not use).

Step 5: Give Telegram a reachable HTTPS URL (N8N_WEBHOOK_URL)

If last_error_message says Telegram cannot reach your n8n at all, the registered URL is wrong or unreachable. n8n builds webhook URLs from N8N_PROTOCOL, N8N_HOST, and N8N_PORT unless you override with N8N_WEBHOOK_URL, and behind a reverse proxy that composition breaks, because n8n listens internally on port 5678 while the proxy exposes it on 443.

The fix, per n8n’s reverse-proxy webhook guide, is to set the public URL explicitly:

# docker-compose.yml
services:
  n8n:
    environment:
      - N8N_WEBHOOK_URL=https://n8n.example.com

(Use N8N_WEBHOOK_URL on n8n 2.30.0 or later; the older WEBHOOK_URL is deprecated since 2.35.0. Never set both.) After changing it, restart n8n, re-activate the workflow so the webhook re-registers with the corrected URL, and re-run Step 1 to confirm the url field now shows the public domain.

Two hard constraints from Telegram’s side, both from the setWebhook documentation:

• The webhook URL must be HTTPS. Plain HTTP registrations are rejected, so http:// in N8N_WEBHOOK_URL fails at registration time.
• Telegram only delivers to ports 443, 80, 88, and 8443. An n8n exposed on a custom port like :8444 or :5678 directly will never receive updates, no matter what the URL says.

n8n Cloud instances satisfy all of this automatically, which is why the same workflow that is dead on a misconfigured VPS works instantly on Cloud. If you are self-hosting and still setting up, our Docker Compose setup guide for n8n walks through the domain and TLS pieces, and our webhook 404 fix guide covers the Nginx header and path-rewriting traps that produce the same symptoms.

Step 6: Check the event type and the chat/user filters

The last silent killer lives inside the node itself. Two settings filter updates before your workflow ever sees them:

• Event type. The default * event covers all update types except Chat Member, Message Reaction, and Message Reaction Count, matching Telegram’s own default for allowed_updates. If your test is a reaction or a membership change, the default trigger correctly ignores it. Pick the specific event you need, or keep * and test with a plain text message.
• Restrict to Chat IDs / Restrict to User IDs. These options drop every update that does not come from the listed IDs. They fail silently by design, which makes a typo here look exactly like a dead trigger. Double-check the IDs: supergroup and channel IDs are negative and start with -100 (for example -1001234567890), while private chat IDs are positive. If you copied the ID from a forwarded message header, verify it against a fresh message, because migrated groups get new IDs.

A fast isolation test: temporarily clear both restriction fields, set the event to Message, and send the bot a direct message. If the trigger fires in DM but not in your group, you are back to Step 4. If it fires nowhere, return to Steps 1 through 3.

Troubleshooting

last_error_message says “Wrong response from the webhook: 404 Not Found”. Telegram reached your server, but the path does not exist. Either the workflow is inactive (the production route was unregistered, Step 2) or the registered URL has the wrong host or path (Step 5). Compare the url from Step 1 character by character with the Production URL in the node panel.

last_error_message says “Connection timed out” or the field repeats “Couldn’t connect to server”. Telegram cannot reach n8n at all. Check that the domain resolves publicly, that ports 443/80 are open through your firewall and proxy, and that N8N_WEBHOOK_URL is the public URL, not localhost or an internal IP. If you run n8n at home without a public IP, a tunnel (for example Cloudflare Tunnel) that forwards /webhook/ paths unchanged is the standard fix.

The trigger worked yesterday and died overnight with no changes. Something re-registered the webhook: a second n8n instance sharing the token, a redeploy that briefly deactivated the workflow, or an expired test registration. Run Step 1, compare the URL, and run Step 3 if it is not yours.

pending_update_count climbs into the hundreds. Telegram is backing off after repeated delivery failures. Fix the root cause (Steps 2 and 5), then call deleteWebhook with drop_pending_updates=true to clear the stale queue and re-activate. Otherwise the first successful delivery dumps hours of old messages into your workflow at once.

The bot answers in BotFather’s test but the trigger ignores channel posts. Two requirements, both from Step 4: the event must be set to Channel Post (or *), and the bot must be a channel administrator. A bot that merely joined the channel receives nothing.

FAQ

The six questions readers ask most are answered in the FAQ block below this article: why the trigger dies when you close the editor, whether two workflows can share one bot token, why a public HTTPS URL is mandatory, where a mystery webhook URL came from, how BotFather privacy mode explains group silence, and what to do after regenerating the bot token.

Conclusion

A dead Telegram Trigger is almost never a broken node. It is a webhook registration problem, a token-sharing problem, a privacy-mode problem, or a URL-reachability problem, in roughly that order. Work the six steps in order and let getWebhookInfo tell you which one you are looking at. Next, if you self-host n8n and keep hitting webhook issues, read our guide to fixing n8n’s webhook-not-registered 404 errors, and if your instance is due for maintenance, see how to update a self-hosted n8n instance.

Frequently asked questions