Telegram Bot 409 Conflict: "Terminated by Other getUpdates Request" and How to Fix It (2026)

By · Published 2026-10-30 · Last verified 2026-10-30

What does "409 Conflict: terminated by other getUpdates request" mean?

It means Telegram received two competing ways of collecting the same bot's updates, and it refused one of them. The Bot API returns HTTP error code 409 with a description such as Conflict: terminated by other getUpdates request; make sure that only one bot instance is running when two processes long-poll getUpdates with the same token at the same time. A close cousin, Conflict: can't use getUpdates method while webhook is active, appears when a webhook is set and something still calls getUpdates. Both have the same root cause: one token, more than one consumer. This guide explains why Telegram enforces a single consumer, the five situations that usually cause the error, and a fix order that doesn't lose or duplicate updates.

This is a troubleshooting guide for people who run their own Telegram bots, including scheduling pipelines like the one Auto X uses. Error texts above are the ones bots commonly log; the rules behind them come from Telegram's Bot API documentation.

Why Telegram allows only one consumer

Telegram offers two mutually exclusive ways to receive updates. With getUpdates your bot asks for updates (long polling). With setWebhook Telegram pushes each update to your HTTPS URL. The Bot API documentation is explicit that getUpdates will not work if an outgoing webhook is set up. Updates are kept on Telegram's servers until your bot receives them, but not longer than 24 hours.

Polling also has a built-in acknowledgement. Each update has an update_id, and an update is confirmed as soon as getUpdates is called with an offset higher than its ID. If two processes poll at once, each one would be confirming updates the other hasn't processed yet. In practice Telegram ends one of the competing requests with a 409, so two pollers never split the work cleanly; they just produce an error loop.

Two columns comparing getUpdates polling, which needs exactly one process and fails while a webhook is set, with setWebhook push delivery to an HTTPS URL on ports 443, 80, 88 or 8443
One token, one way to get updates.

The five usual causes

1. An old instance is still running

The most common cause. A previous deploy, a screen or tmux session, a crashed container that restarted, or a laptop you forgot to stop is still polling with the same token. Each new poll kills the other's request, and both log 409 in turn.

2. Rolling deploys overlap

Platforms that start the new version before stopping the old one create a window where two pollers exist. It may last seconds, but if the platform keeps both running during health checks, the conflict can repeat for minutes.

3. More than one replica

Scaling a polling bot to two or more replicas guarantees the error. Polling bots must run as exactly one process per token. If you need horizontal scale, switch to a webhook and let your load balancer spread requests.

4. A webhook is still set

You moved from webhook hosting back to polling, or a test tool set a webhook, and now getUpdates fails with the "webhook is active" conflict. getWebhookInfo tells you: if the bot is using getUpdates, its url field is empty.

5. The same token is shared between bots or environments

Staging and production using one token, or a library test suite running against the live token, behave like two instances. Give each environment its own bot from BotFather.

Grid of five usual causes of a Telegram 409 Conflict: an old instance still polling, a rolling deploy, two replicas, a webhook still set and a token shared between environments
Five usual causes.

A fix order that doesn't lose updates

  1. Find every consumer. List processes, containers and scheduled jobs that load the token. Check old hosts too. If you can't find the other instance, treat the token as possibly leaked.
  2. Check the webhook. Call getWebhookInfo. A non-empty url means a webhook is active. Look at pending_update_count and last_error_message before changing anything.
  3. Pick one mode. To poll, call deleteWebhook. It accepts drop_pending_updates; leave it false if you want the queued updates, and set it to true only when you deliberately want a clean slate. To use a webhook, stop every poller first, then call setWebhook.
  4. Restart one instance. Start a single poller and watch the log for a few minutes. No 409 means you've removed the competitor.
  5. Make processing idempotent. During the conflict, some updates may have been fetched by one process and confirmed by the other. Store processed update_id values and skip repeats, as covered in our guide to webhook secret tokens and update_id dedupe.
Four steps to fix a 409 Conflict: find every process using the token, check getWebhookInfo, delete the webhook or stop pollers, then restart a single instance
Fix order.

Don't reach for close or logOut first

Two Bot API methods look like a quick reset but have side effects. close closes the bot instance before moving it from one local server to another; the documentation says to delete the webhook before calling it, and the method returns error 429 in the first 10 minutes after the bot is launched. logOut logs the bot out of the cloud Bot API server before you run it locally, and after a successful call you can't log in again using the same token for 10 minutes. Neither is needed to fix an ordinary 409, and using them during an incident can turn a short conflict into a longer outage.

Likewise, regenerating the token in BotFather stops any unknown instance immediately, but every legitimate deployment must be updated with the new token. Use it when you suspect a leaked token, not as the first step.

Deploy settings that prevent it

Two columns of deploy settings: a polling bot with one replica and stop-then-start deploys, and a webhook bot with replicas but no polling on the same token
Deploy settings that prevent it.

How this applies to Auto X

Auto X schedules X posts from Telegram, so its bot receives your messages and commands through one controlled consumer. You don't run any part of it yourself, so this error isn't something Auto X users have to fix. If you're building your own Telegram-to-X pipeline, a 409 loop is a classic reason scheduled items go missing: the bot never sees the message that should have queued the post. Our checklist on why a scheduled post didn't go out covers the X side, and failed publish retries and dead-letter queues covers what to do with items that fail later.

Vertical Pinterest graphic with five points for fixing a Telegram bot 409 Conflict
Pinterest pin: Telegram bot 409 Conflict.

FAQ

Does a 409 Conflict mean my bot token was stolen?

Usually not. Most cases are an old instance or overlapping deploy. If you've checked every host and the conflict continues, assume the token is in someone else's hands and regenerate it in BotFather.

Will I lose messages when I call deleteWebhook?

Not if you leave drop_pending_updates unset or false. Pending updates stay available, for up to 24 hours, to your poller. Setting it to true discards them.

Can I run getUpdates and a webhook at the same time?

No. The Bot API states that getUpdates will not work while an outgoing webhook is set up. Choose one method per token.

Why does the error come back after every deploy?

Your platform is probably starting the new version before stopping the old one. Switch the polling bot to a single-replica, stop-then-start deploy, or move it to a webhook.

Sources