When something breaks
Telegram bot 409 Conflict: terminated by other getUpdates request
In short
The error terminated by other getUpdates request means two copies of your bot are asking Telegram for updates with the same token. Telegram hands the update queue to one receiver at a time, so the second copy takes it over and the first one gets a 409 Conflict, then they keep stealing the queue from each other and the bot replies only every other time. Most often the extra copy is the bot still running on your laptop or on an old server, or the same project published twice, so stop every copy except one. There is one more case with the same error code: a webhook is set while your code polls getUpdates, and then the webhook has to be deleted.
The bot used to work, and now it replies every other time or stays silent, while the logs keep repeating terminated by other getUpdates request. Next to it there is usually a 409 Conflict code and a suggestion to make sure only one bot instance is running. This is not a bug in your code, not an outage at Telegram and not a hosting problem: it is what two copies of the same bot fighting over one update queue looks like. Moving the bot to another server changes nothing by itself, because the extra copy still has to be found and stopped.
Telegram gives new messages to a single receiver. When a second copy shows up with the same token, it takes the queue over and the first copy gets this error. Then the first copy asks again and pushes the second one out, and so on in a loop, which is why some messages get lost and the bot looks like it answers at random. Below is how to find the extra copy and how to keep this from coming back.
Stop the bot running on your own computer#
The most common second copy is the same bot still running in a terminal window, in an editor tab or in a minimized window on your laptop. Close the window you started it from, stop the process in your editor, and check the other projects you have open next to it, because the bot could have been started from any of them. If you once added the bot to autostart, it comes back on its own after every reboot and is easy to forget about.
Check the old server and every other place you ever started it#
The second copy often lives where the bot used to be hosted: an old VPS, an account on another hosting service, a work computer, a borrowed laptop you once used to demo the bot. As long as that process is alive it keeps taking messages, because it will not stop by itself and knows nothing about the move. Go through every place the bot was ever started and shut it down everywhere but one.
Make sure the project is published only once#
Sometimes the bot is simply published twice: the first project was never deleted and a second one was created next to it with the same BotFather token. Open your project list, find the duplicate and stop or delete it, so that exactly one stays running. If your host shows live logs and a project status, the duplicate is easy to spot: the logs of the extra copy contain the very same terminated by other getUpdates request line.
Delete the webhook if your bot uses polling#
The same conflict happens when a webhook is set for the bot, meaning Telegram pushes updates to your address, while your code also polls Telegram with getUpdates. The message text is different in that case, but the code is the same 409 Conflict. Check the webhook with getWebhookInfo and, if one is set while you want to use polling, remove it with deleteWebhook. Many libraries can drop the webhook for you at startup with a single option.
Restart the bot and give it a minute#
Once the extra copies are off, restart the remaining bot and wait about a minute. The previous request to Telegram lives until its own timeout, so the error can flash a couple more times and then disappear on its own, and a restart itself is a classic trigger: the new copy is already up while the old one has not finished shutting down. If the error is still repeating after a few minutes, a copy you have not found yet is running somewhere, so go back to the earlier steps.
Use a separate test bot for local debugging#
A practical rule for the future: the real bot lives in one place, and on your computer you run a separate test bot with its own token. Create a second bot in BotFather, give it an obvious name such as my bot test, and keep its token apart from the production one. After that your local experiments stop knocking the real bot offline, and there is simply nobody left to create the conflict.
The error terminated by other getUpdates request almost always has the same cure: make sure exactly one copy of the bot is asking Telegram for updates. That is easiest when the bot does not live on a laptop you keep closing, but in one permanent place. On Netrun you upload the code, provide the BotFather token, and the bot runs on its own, with status and live logs in your dashboard, so an extra copy or a restart loop is visible right away. On the free plan a bot runs for three days and is then switched off, while your code, settings and token stay in place. Keep local debugging on a test bot with a different token. Try Netrun.
Common questions
What does error 409 Conflict from Telegram mean?
It is the code Telegram returns when two clients ask for the same updates at once. The message next to it says the request was terminated by another getUpdates request and asks you to make sure only one bot instance is running. The same 409 code also appears in a different situation: a webhook is set for the bot while the code tries to fetch updates by polling.
Why did the error appear right after I deployed the bot to a host?
Because the copy on your computer is usually still running. As soon as the copy on the server starts receiving updates the two collide, and the logs fill up with terminated by other getUpdates request. Stop the local run and within a minute the hosted bot starts replying normally.
Why does the bot reply only every other message?
That is what a conflict between two copies looks like: each one grabs the update queue in turn, and part of the messages goes to the copy you no longer consider the real one. From the outside it looks like random replies and missed commands. As soon as a single copy is left, the behavior becomes consistent.
Can I run one bot on two servers for reliability?
No. With polling this gives you no redundancy and breaks the bot instead: the copies keep pushing each other out and messages get lost. One token means one running copy. Get reliability another way: host the bot where the project is watched and brought back up after a failure.
How do I check whether a webhook is set for my bot?
Telegram has a getWebhookInfo method that shows whether a webhook URL is configured. If there is one and you want polling, remove it with deleteWebhook. If you would rather stay on the webhook, take the polling loop out of your code instead, because only one of the two can be active.
Will revoking the token in BotFather help?
Revoking the token is a last resort, but it works when the extra copy is physically out of reach, for example it sits on a server you no longer have access to. After the revoke the old token stops working for every copy that was using it. You will then have to put the new token into your project settings, otherwise the bot will not start.
Can I host a Telegram bot?
Yes. Upload the bot code and provide the token from BotFather (Telegram itself gives it to you when you create the bot) — Netrun starts the bot, and no VPS or manual setup is needed. On the free plan the bot runs for 3 days so you can check everything; to keep it running around the clock, switch to the Pro plan.
Where can I see the logs and status of my project?
The project page shows the status, the logs and the event history — together they show what is happening with the project right now. The log view also reaches further back: scroll up and earlier lines load on their own.
What happens if my app crashes?
We watch over projects and restart them if they fail. If something goes wrong, you can see the status and logs in your account and you get a notification.