n8n Telegram Trigger Not Working: HTTPS Webhook Fixes

If your n8n Telegram Trigger is not working, Telegram almost certainly has the wrong webhook URL for your bot: an http:// or localhost address it refuses, a test URL that overwrote production, or a URL set by hand that n8n rejects. Run getWebhookInfo (below), read the url and last_error_message fields, and apply the matching fix.

Why it bites founders: Telegram allows one webhook per bot, and only over HTTPS on ports 443, 80, 88 or 8443. A support bot or lead-capture bot can look healthy on the canvas while every customer message in production goes nowhere.

Free downloads

• Telegram webhook health-check workflow (JSON): import into n8n, paste your bot token and public URL, run it. It calls getWebhookInfo and tells you in plain English whether you’re on the test URL, on http, on a bad port, or getting 403/404/TLS errors. It also has an optional deleteWebhook node for a clean reset.
• docker-compose.yml: n8n behind Caddy with HTTPS: n8n plus Caddy with automatic certificates, N8N_WEBHOOK_URL/WEBHOOK_URL and N8N_PROXY_HOPS already set. Placeholders only; swap in your domain.

Checked on 4 Nov 2026 against docs.n8n.io, the Telegram Bot API docs and the Telegram Trigger source on GitHub. We haven’t run these on our own instance; behavior described is per docs and source. n8n now says “publish” where older threads say “activate”.

Step 1: ask Telegram what it has

Replace <TOKEN> with your bot token (keep the word bot in front of it):

curl -s https://api.telegram.org/bot<TOKEN>/getWebhookInfo

Telegram’s docs list the fields that matter: url (empty if no webhook is set), pending_update_count, last_error_date, last_error_message, ip_address and allowed_updates. A healthy n8n production registration looks like https://YOUR-DOMAIN/webhook/<id>/webhook, because the Telegram Trigger’s webhook path is webhook (per the node source).

Symptom → cause → fix

Fix 1: give n8n a public HTTPS URL

When the Telegram Trigger activates, n8n calls Telegram’s setWebhook with its own webhook URL. Telegram only accepts HTTPS, so if n8n thinks it lives at http://localhost:5678, you get the “An HTTPS URL must be provided” error. n8n’s docs explain why: it builds webhook URLs from N8N_PROTOCOL, N8N_HOST and N8N_PORT, which is wrong behind a reverse proxy that exposes port 443 while n8n listens on 5678.

The fix, per n8n’s reverse-proxy page:

export N8N_WEBHOOK_URL=https://n8n.example.com/
export N8N_PROXY_HOPS=1

• On the last proxy, pass X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Proto.
• Which name? n8n’s endpoints reference says WEBHOOK_URL is deprecated from n8n 2.35.0 and is now an alias of N8N_WEBHOOK_URL. It still works but logs a warning. Older versions only read WEBHOOK_URL. Our compose file sets both to the same value, which covers either case. The Telegram common-issues page still says WEBHOOK_URL.
• Restart n8n, then unpublish and publish the Telegram workflow so it registers the new URL.

Running on your laptop? Telegram can’t reach localhost. In GitHub issue #13682 an n8n team member closed the “bug” and pointed to a tunnel such as ngrok or Cloudflare, or a reverse proxy with WEBHOOK_URL set to your domain. Skip n8n’s own --tunnel flag for this: in a community thread n8n staff call it testing-only and say it swaps your webhook URL for a randomly generated one.

On n8n Cloud? HTTPS is handled for you, so skip to Fix 3.

Fix 2: meet Telegram’s network rules

Telegram’s webhook guide lists what your server must do:

If last_error_message mentions a certificate or a timeout, test from outside your network, as Telegram’s guide suggests: openssl s_client -tls1_2 -connect n8n.example.com:443 -servername n8n.example.com.

The stuck “Listen for test event” problem is different. n8n’s docs say it usually means your reverse proxy isn’t configured for WebSocket proxying, so check that setting in nginx, Caddy, Apache or Traefik. Caddy’s reverse_proxy handles WebSocket upgrades and sets the three X-Forwarded-* headers by default, which is why our compose file uses it. If the canvas stays stuck, n8n’s docs say to exit the workflow and open it again.

Fix 3: stop test and production fighting over one webhook

This is the most common “it worked yesterday” cause. n8n’s docs: “Telegram only allows you to register a single webhook per app.” Each time you switch between the test URL and the production URL, Telegram overwrites the registered one. The node even shows a notice: one Telegram trigger per bot at a time.

So the sequence that breaks production is:

1. Workflow is published; Telegram points at /webhook/....
2. You click Execute workflow to debug. n8n registers /webhook-test/....
3. You stop testing. Telegram is left pointing at the test URL, which no longer listens (or at nothing, if the test listener removed it). Production is silent.

n8n’s docs give two workarounds:

• Unpublish while testing, publish when done. Publishing registers the production URL again. The catch: production traffic stops while the workflow is unpublished.
• Use a separate bot for testing. A community answer spells out the routine: create the second bot, save it as its own Telegram credential, build against it, and switch back to the live bot’s credential before you publish. This is the cleaner option once real users depend on the bot.

Then confirm with getWebhookInfo that url contains /webhook/, not /webhook-test/. Production runs don’t appear on the canvas, so check the workflow’s Executions tab.

Fix 4: one bot, one consumer

Telegram’s two ways of receiving updates, getUpdates polling and webhooks, are mutually exclusive, and a bot has one webhook. Anything else holding your token can steal it:

• A second Telegram Trigger in another workflow using the same bot. Each activation re-registers the bot’s one webhook, so the last one wins.
• A second n8n instance: an old trial, a local Docker copy, a staging server.
• A script or library using the same token. A community answer notes that some polling libraries call deleteWebhook on their own when getUpdates is refused, which silently wipes n8n’s registration.

If getWebhookInfo shows an unfamiliar domain, or the url keeps going empty, hunt down every place the token has been pasted and shut those consumers down.

Fix 5: reset cleanly with deleteWebhook

When the registration is stale or set by hand, clear it and let n8n set it again:

# 1. Unpublish the workflow that holds the Telegram Trigger, then:
curl -s https://api.telegram.org/bot<TOKEN>/deleteWebhook

# 2. Confirm url is now empty
curl -s https://api.telegram.org/bot<TOKEN>/getWebhookInfo

# 3. Publish the workflow in n8n, then run getWebhookInfo again

Add ?drop_pending_updates=true to step 1 only if you want to throw away queued messages.

Why not just setWebhook to your n8n URL yourself? Because n8n won’t accept it. Per the node source, when n8n registers the webhook it sends a secret_token built from the workflow and node IDs. Telegram then sends that value in the X-Telegram-Bot-Api-Secret-Token header, and from node version 1.1 the trigger answers anything without a match with 403 {"message":"Provided secret is not valid"}. A hand-made setWebhook has no matching secret, which is exactly the “Wrong response from the webhook: 403 Forbidden” error people post on the n8n forum.

Worked example: a weekend outage and lost messages

A founder runs a support bot on self-hosted n8n. On Friday at 6 p.m. they debug on the canvas, which re-points the bot to the test URL, and leave for the weekend. On Saturday at 9 p.m. they notice and republish.

• Downtime: Friday 6 p.m. to Saturday 9 p.m. = 27 hours.
• Telegram keeps undelivered updates for at most 24 hours (per the Bot API docs), so messages from the first 3 hours (6 to 9 p.m. Friday) are gone whatever happens.
• It’s worse than that. Per the source, node version 1.3 and later send drop_pending_updates: true when registering the webhook. Republishing a current trigger clears the queue, so the other 24 hours of messages are discarded too, unless the founder pulls them first (remove the webhook without dropping updates, then call getUpdates).

The fix is cheap: a second bot for testing, plus the hourly health-check workflow alerting on /webhook-test/ or a growing pending_update_count. (Illustrative scenario; your times will differ.)

Who this guide is for, and who it isn’t

• For: self-hosters on Docker, a VPS or a home server behind nginx, Caddy or Traefik; anyone whose bot works on the canvas but not in production.
• Not for: n8n Cloud users seeing TLS or “HTTPS URL must be provided” errors. Cloud handles HTTPS, so look at Fixes 3 to 5 instead.
• Building a bot for customers, not just yourself? If WhatsApp is on the table too, compare the running costs in n8n WhatsApp chatbot cost. If the problem is a plain Webhook node rather than Telegram, see n8n production webhook not working.

Notes for US, Canada and Australia

None of this varies by country: Telegram’s rules and n8n’s behavior are the same everywhere. One practical point for Vancouver, Toronto, Sydney or Perth founders self-hosting: set GENERIC_TIMEZONE to your own zone (our compose file uses America/Toronto as a placeholder) so schedules and timestamps in your bot workflows match your day. More on the self-hosting trade-offs in the AI automation hub.

General information for founders running n8n, not professional advice. n8n and Telegram change their APIs; confirm against the docs for your version. Checked on 4 Nov 2026.