When something breaks
Telegram bot 429 Too Many Requests: what retry after means
In short
Error 429 Too Many Requests: retry after N means your bot sends messages faster than Telegram allows and has to wait N seconds. According to the official Telegram bot FAQ, a bot should send no more than one message per second to a single chat, no more than 20 messages per minute to a group, and bulk broadcasts are capped at about 30 messages per second. The fix is pauses between sends, a message queue, and honoring the retry_after value before repeating the request. Changing hosts does not help, because the limits belong to the bot, not to the server.
- Telegram returns 429 Too Many Requests when a bot exceeds its message sending limits.
- The retry_after field in a 429 response tells the bot how many seconds to wait before trying again.
- According to the Telegram bot FAQ, a bot should not send more than one message per second to a chat or more than 20 messages per minute to a group.
- Free bulk broadcasting on Telegram is limited to about 30 messages per second.
- python-telegram-bot ships a built-in AIORateLimiter that is installed separately with pip install "python-telegram-bot[rate-limiter]".
The bot worked fine with ten users, and then a broadcast to the whole list filled the logs with Too Many Requests: retry after 35. Some people got the message and some did not, and for a while the bot answers with a delay. This is not a ban and not a bug: Telegram limits how fast a bot may send messages, and a 429 error is its way of asking the bot to slow down.
The useful part is that Telegram tells you how long to wait right in the error: the number after retry after is in seconds. If the bot waits and repeats the request, the message goes through. If it keeps firing messages, the wait only grows. Below are the actual limits, how to handle retry_after properly, and how to run a broadcast so the error does not appear at all.
| Destination | Limit | What happens when exceeded |
|---|---|---|
| A single private chat | No more than 1 message per second, short bursts are tolerated | 429 errors with retry_after |
| A single group | No more than 20 messages per minute | 429 errors with retry_after |
| A broadcast to many users | About 30 messages per second | 429 errors, the broadcast slows down or stops |
| Paid broadcasts | Up to 1000 messages per second, with messages above 30 per second paid in Telegram Stars | Only for large bots: a balance of at least 100,000 Stars and at least 100,000 monthly active users |
Find out in the logs where the bot hits the limit#
Open the logs and look at when the 429 error appears and on which action. If it happens during a broadcast, the problem is bulk sending speed. If it happens in one group, the bot posts there more than 20 times a minute. If it happens in one chat, the bot replies with several messages in a row or keeps editing the same message, and edits count as requests too. The fix depends on the place: pauses in the broadcast, merging messages, or updating less often.
Wait exactly as long as retry_after says#
With a 429 error Telegram returns a retry_after field, the number of seconds after which the request may be repeated. There is one correct reaction: catch the error, wait that long and send the same message again. In aiogram this is the TelegramRetryAfter exception with a retry_after field, in python-telegram-bot it is the RetryAfter exception. Do not retry right away and do not silently drop the message: the first makes the wait longer, the second means the person never gets anything.
Send broadcasts with pauses, not all at once#
The most common cause of 429 is a broadcast to the whole list in one loop with no pauses, or with hundreds of parallel requests. Send messages one by one with a short pause between them so you stay well below 30 messages per second, for example one message every 50 to 100 milliseconds. For a list of a few thousand people the broadcast takes minutes rather than seconds, and that is fine. Record who already got the message, so that after a failure you continue where you stopped instead of messaging everyone again.
Use a queue or the library rate limiter#
Instead of hand-made pauses you can add a limiter that keeps the pace for you. python-telegram-bot has AIORateLimiter: install it separately with pip install "python-telegram-bot[rate-limiter]", and by default it keeps 30 requests per second overall and 20 per minute per group; retries after 429 are off by default and are turned on with the max_retries parameter. aiogram has no built-in sending limiter, so broadcasts there are usually built with your own queue: tasks go into a list and are sent at a fixed pace, and a 429 error pauses the queue.
Send fewer messages#
Often 429 is fixed not by pauses but by sending less. Merge three messages in a row into one, and instead of a new message for every update, edit a single one, but no more often than once every few seconds. If the bot reports progress of a long task, update it on a timer rather than on every step. In groups it is especially important to stay under 20 messages per minute, because the limit there is stricter than in private chats.
Handle sending errors so the bot does not crash#
An uncaught 429 can stop a handler or the whole broadcast, and the bot looks frozen. Wrap sending in error handling: on 429 wait and retry, and on a bot was blocked by the user error skip that person and mark them in your database so you never write to them again. That way the broadcast reaches the end, and people who blocked the bot no longer eat into your limit on every send.
Error 429 Too Many Requests is not a punishment but a request from Telegram to slow down, and it already says how long to wait. Keep the pace under the limits, wait for the retry_after time and repeat the request, and run broadcasts through a queue with pauses, and the error goes away. Hosting does not make this faster or slower: the limits are the same for a bot on any server. On Netrun the bot logs stream live in your dashboard, so a 429 and the place it comes from are visible right away, and broadcasts that must go out at any time of day need the Pro plan with round-the-clock running. Try Netrun.
Common questions
What does retry after mean in a Telegram error?
It is the number of seconds the bot must wait before sending requests again. Telegram returns it together with the 429 Too Many Requests error. Wait that long and repeat the same request, and the message will go through.
How many messages per second can a Telegram bot send?
According to the official Telegram FAQ, no more than one message per second to a single chat, no more than 20 per minute to a single group, and about 30 messages per second for a broadcast to many users. Very large bots can use paid broadcasts of up to 1000 messages per second.
Can Telegram ban my bot for 429 errors?
A 429 error itself is a temporary limit, not a ban: wait the retry_after time and the bot can send again. But if the bot keeps ignoring that time and firing requests, the waits get longer. Broadcasts that many people report as spam are a separate matter, and there the risk to the bot is higher.
Will moving the bot to another server help?
No. Telegram limits are tied to the bot, meaning its token, not to the server or IP address. A bot on any host runs into the same limits, so the only fix is the sending pace in your code.
How do I message every user of my bot without errors?
Send one message at a time with a short pause, staying well below 30 messages per second, catch the 429 error and wait the retry_after time. Keep track of who already got the message so a failure does not force you to start over, and skip users who blocked the bot.
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 hours 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.