Telegram Trigger runs each message 3 times (duplicate executions)

Questions
1

Describe the problem/error/question

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
2

@Wey89_Gmail that almost always means the same bot token is active in more than one Telegram Trigger, so each copy processes the same update. 3x = its live in 3 places. check for a duplicated/copied workflow, a test and a production version both active, or another n8n instance using the same bot, and deactivate the extras. telegram only allows one active trigger per bot, once theres just one the duplicates stop.

3

Telegram Trigger firing 3x per message is almost always one of two causes:

  1. More than one consumer is attached to the same bot token. Telegram allows only ONE active receiver per bot — either polling (getUpdates) or a single webhook, never both, and never across multiple instances. If the same bot token is used in another workflow, another n8n instance, or there’s a leftover webhook from a previous activation, Telegram delivers the same update to each one → duplicates.
    Check it: call Telegram’s getWebhookInfo method for your bot token — it shows whether a webhook is currently set plus the pending update count. If you’re using the n8n Telegram Trigger (which polls), make sure no webhook is set (use deleteWebhook to clear a stale one), and confirm the token isn’t active in a second workflow/instance.

  2. Telegram is retrying because it didn’t get a fast 200. If the trigger doesn’t acknowledge within Telegram’s timeout, Telegram re-sends the same update — you’ll often see it land 2-3 times. This happens when heavy work runs before the response is sent. Fix: acknowledge immediately and offload the slow steps (respond first, then do the LLM/API work, or push it to a queue). Three resends is a classic Telegram retry signature.

How to tell them apart: if getWebhookInfo shows a webhook set while you’re also polling, it’s #1. If the duplicates are a few seconds apart and your workflow is slow, it’s #2.

Fix that stops dupes regardless of cause: add a dedupe guard right after the trigger — store each Telegram update_id (or message_id) and skip if you’ve already processed it. That makes the workflow idempotent even if Telegram double-delivers.

What’s your setup — self-hosted with more than one instance, and are you on polling or webhook? That’ll pin it down.