Telegram flood wait: what “A wait of X seconds is required” means, and how to stay under the limits

veltrisltd — Sun, 25 Oct 2026 13:55:50 +0000

In short

A flood wait is a timer, not a ban: Telegram names the seconds, and the fix is to wait all of them before trying that request again.
Telegram publishes limits for bots only; for user accounts it doesn’t, so pace each account conservatively instead of hunting for the edge.
Retry loops and bursts make waits come back. Space messages out, and never move the same send to another account to keep going.

A Telegram flood wait is Telegram telling an account or bot to stop repeating a request for a set time. The error FLOOD_WAIT_X means “A wait of X seconds is required”. On its own it isn’t a ban. Wait the full X seconds, try once more, then space your sends out so it stops coming back.

What is a Telegram flood wait?

Telegram’s API error reference files it under error code 420 FLOOD: “The maximum allowed number of attempts to invoke the given method with the given input parameters has been exceeded.” The example Telegram gives is asking for a large number of login codes by SMS for the same phone number.

Two things in that definition matter. The limit is per method and input: a wait applies to that request (for example, codes for one phone number), not necessarily to everything the account does. And it counts attempts, so a failed request that you fire again straight away is one more attempt, not a fresh start.

Flood wait when you log in to the Telegram app

If you aren’t writing code and simply get told to wait while signing in, the cause is the same mechanism. Asking for a login code again and again for one number triggers PHONE_NUMBER_FLOOD (“You asked for the code too many times”, per auth.sendCode), and each number gets only a certain number of login attempts per day, after which Telegram returns a FLOOD error until the next day. The fix is to stop requesting codes and wait; there is nothing to repair on the account.

What the number X tells you

X is the number of seconds Telegram wants you to wait before repeating the request. Telegram doesn’t publish a range or a maximum, and it doesn’t explain how it picks the number, so treat each value as an instruction rather than a guess to beat. Your code should read the number from the error, not assume a fixed pause.

How it shows up in Telethon and the Bot API

User accounts and MTProto libraries. In Telethon, a Python MTProto library, it arrives as FloodWaitError with the wait in .seconds. By default the library sleeps through flood waits shorter than 60 seconds on its own, so your code only sees the longer ones (Telethon docs).
Bots on the HTTP Bot API. The same idea comes back as a 429 Too Many Requests error. Its retry_after field is, in Telegram’s words, “the number of seconds left to wait before the request can be repeated” (Bot API reference).

Flood wait, slow mode, 429 or FLOOD_PREMIUM_WAIT: which is it?

Several Telegram errors carry a number of seconds, and they don’t all mean you sent too much. Read the error’s name before you change anything.

Telegram errors that ask you to wait

Error	Where you meet it	What it means	What to do
`FLOOD_WAIT_X` (420)	Any API method, from a user account or an MTProto bot	You repeated a request too often; wait X seconds	Pause that action for all X seconds, then try once more
`SLOWMODE_WAIT_X` (420)	Posting in a group where an admin turned on slow mode	Slow mode is on in that chat: wait X seconds before sending another message there	Wait before posting in that group again; it is the group’s own setting, not a mark against the account
429 Too Many Requests	Bots on the HTTP Bot API	The bot went over a flood limit; `retry_after` gives the seconds left	Wait `retry_after` seconds, then repeat the request
`FLOOD_PREMIUM_WAIT_X`	Uploading or downloading files on an account without Premium	Transfer speed is limited, and the client repeats the request after X seconds	Nothing to fix in your sending; it concerns file speed, not messages
`PHONE_NUMBER_FLOOD`	Asking for a login code	“You asked for the code too many times.”	Stop requesting codes and try again later

Slow mode is not new: Telegram added it for groups in August 2019, and a timer in the app shows how long you have to wait. FLOOD_PREMIUM_WAIT_X is not new either, and it is not about messages at all. Telegram’s file transfer documentation says it limits upload or download speed for accounts without Premium, and that it “can only be received when the user has uploaded tens of gigabytes or more.”

If a message fails with a different error, or with no wait at all, the cause is usually somewhere else: a chat you can’t write in, a restriction, a session that needs signing in again. The guide to why a Telegram message isn’t sending walks through those.

Which Telegram rate limits are published?

For bots, Telegram publishes rough figures in its Bots FAQ:

In a single chat, avoid more than about one message per second. Telegram may allow short bursts, but “eventually you’ll begin receiving 429 errors.”
In a group, a bot can’t send more than 20 messages per minute.
For bulk notifications, a bot can’t broadcast to more than about 30 users per second unless it turns on paid broadcasts.

For user accounts, Telegram publishes no message limits at all. The only figure in its authorisation documentation is about sign-in: each phone number gets a certain number of login attempts per day, with 5 given as an example that is “subject to change”, after which the API returns a FLOOD error until the next day.

Library authors say the same. The grammY bot framework’s guide to flood limits puts it bluntly: the exact numbers “are unspecified”, and they shift with the requests, the number of users and other factors. Any tool or blog that quotes a precise daily message limit for user accounts is guessing.

Since Telegram’s 7 May 2026 update, bots can respond to other bots, and any user can connect a bot to their profile to answer messages on their behalf, under Settings > Chat Automation. Telegram hasn’t published separate limits for either, so treat them like any other bot or account: read the wait, and respect it.

Why a short flood wait turns into a long one

Telegram doesn’t document how it sets X, but the definition above tells you what it counts: repeated attempts at the same method. The patterns that keep adding attempts are easy to spot:

Retry loops. A script that catches the error and tries again at once, or every few seconds, keeps adding attempts while the timer runs.
Bursts. Fifty messages in a few seconds look very different from fifty spread over an hour, even when the daily total is the same.
Repeating the same request. Resolving the same username, asking for the same login code or re-joining the same group over and over.
Many workers, one account. Several processes sending from one account at once, each unaware the others were told to wait.

A flood wait is also different from a spam limit. Telegram’s spam FAQ describes a limit on an account that others reported for unwanted messages: for a first time it lasts “a few days or so”, and the account can still message people who have its number saved as a contact, and reply to anyone who messages it first. If that is what you are seeing, the guide to a frozen or limited Telegram account covers the appeal.

How to handle a Telegram flood wait correctly

Read the error’s name and number. Check it is FLOOD_WAIT_X or a 429, not slow mode or a file-speed limit, and note X or retry_after.
Stop that action for the whole wait. Pause the request that failed, for that account or bot, for all X seconds. Don’t send a “quick test” in the meantime.
Reschedule long waits instead of sleeping. A wait of a few seconds can be slept through. For minutes or hours, record when the wait ends and move the job to that time, so a worker isn’t held up and nothing retries early.
Try once, then look at your pace. When the wait is over, repeat the request once. If waits keep coming back, the fix is fewer or slower requests, not a smarter retry.
Keep a record. Log each wait with the account, the action and X. A pattern, such as waits every morning when a batch starts, shows you what to spread out.

A sketch in Python with Telethon: wait the full time, then try once more

from telethon import errors

async def send_once_more_after_wait(client, chat, text, reschedule):
    try:
        return await client.send_message(chat, text)
    except errors.FloodWaitError as e:
        # Telegram asked for e.seconds. Don't retry before that.
        # Short waits never reach here: Telethon sleeps through
        # those under its flood_sleep_threshold (60 s by default).
        reschedule(delay_seconds=e.seconds)

For bots, the grammY guide gives the same advice in two steps: wait for the number of seconds Telegram specifies, then retry the request. Its auto-retry plugin does exactly that.

Pacing several accounts: caps, gaps and jitter

If you run several accounts, for a team or for different channels, give each one its own pace rather than one shared queue. Three settings do most of the work:

Caps. A daily and an hourly ceiling per account, set well below anything that has caused a wait before.
A minimum gap. A few seconds between one message and the next from the same account, so nothing goes out in a burst.
Jitter. A small random extra on each gap, so a batch doesn’t fire on the exact same beat every time.

Don’t move the send to another account. When one account gets a flood wait, switching the same messages to a second account to keep the volume up defeats the point of the limit and can look like the flooding that Telegram says gets API users banned forever. Treat the wait as a sign the plan sends too much, too fast, and slow the whole plan down.

If you use the Telegram API for flooding, spamming, faking subscriber and view counters of channels, you will be banned forever.

— Telegram: Creating your Telegram Application

Telegram’s API Terms of Service also forbid making actions on behalf of a user without the user’s knowledge and consent. Message people who expect to hear from you, in groups and channels where you are welcome, and pacing becomes a matter of courtesy rather than a race against a timer.

Paid broadcasts for large bots: when they make sense

Paid broadcasts are the one documented way to raise a Telegram sending limit, and they are for bots only. According to the Bots FAQ, a bot that turns them on in @BotFather can broadcast up to 1,000 messages per second. Each message over the free 30 per second costs 0.1 Stars from the bot’s balance, and Telegram charges only for messages that are delivered.

The bot needs at least 100,000 Stars on its balance and at least 100,000 monthly active users.
On the HTTP Bot API it is the allow_paid_broadcast parameter on send methods; in MTProto it is the allow_paid_floodskip flag on messages.sendMessage, marked bots only.
Without it, Telegram suggests spreading a large broadcast over a longer stretch, 8 to 12 hours for example.

For most bots, spreading the broadcast is the better answer: the recipients opted in, and nobody minds a notice that arrives an hour later. Paid broadcasts make sense for time-sensitive notices to a very large audience that already asked for them. There is no equivalent for user accounts, and nothing in Telegram’s documentation says Premium removes flood waits on messages; the Premium error covers file speed.

A checklist for staying under Telegram’s rate limits

Keep one sender per account at a time, so every worker sees the same wait.
Cache what you look up, such as resolved usernames, instead of asking Telegram again.
Start big batches slowly and spread them over hours, not minutes.
Send only to people and chats that expect your messages.

FAQ

How long does a Telegram flood wait last?

Exactly as long as the number in the error: FLOOD_WAIT_X asks for X seconds, and a bot’s 429 gives retry_after seconds. Telegram doesn’t publish a range or a maximum, so read the number each time. Retrying before it runs out doesn’t shorten it; the request fails again and counts as one more attempt.

Can you skip a Telegram flood wait?

Not for a user account: Telegram documents no way to end a wait early, and moving the same send to another account defeats the limit and risks looking like the flooding Telegram says gets API users banned forever. The only documented way to raise a limit is paid broadcasts, for large bots. For everyone else, wait it out and slow the pace.

Does Telegram Premium remove flood waits?

Not the ones on sending messages, as far as Telegram documents. The error that mentions Premium, FLOOD_PREMIUM_WAIT_X, is about upload and download speed on accounts without Premium, and Telegram says it only appears after tens of gigabytes of transfers. A FLOOD_WAIT_X on messages calls for a slower pace, not a subscription.

How many messages per second can a Telegram bot send?

Telegram’s Bots FAQ says about one per second in a single chat, no more than 20 per minute in a group, and about 30 per second across users for bulk notifications. Bots with at least 100,000 monthly active users and 100,000 Stars can turn on paid broadcasts for up to 1,000 per second, paying 0.1 Stars per message over the free 30.

Why do I get a flood wait when logging in to Telegram?

Because the login code was requested, or a login tried, too many times. Telegram’s own example of a 420 FLOOD is asking for many SMS codes for one number, and PHONE_NUMBER_FLOOD means “You asked for the code too many times.” Stop requesting codes, use the one you already have if it is still valid, and try again later.

Sources

Telegram API: error handling (420 FLOOD) (accessed 2026-09-30)
Telegram API: messages.sendMessage, possible errors (accessed 2026-09-30)
Telegram Bots FAQ: hitting limits and paid broadcasts (accessed 2026-09-30)
Telegram Bot API: ResponseParameters, retry_after (accessed 2026-09-30)
Telegram API: uploading and downloading files (FLOOD_PREMIUM_WAIT_X) (accessed 2026-09-30)
Telegram API: user authorisation, login attempt limits (accessed 2026-09-30)
Telegram API: auth.sendCode, PHONE_NUMBER_FLOOD (accessed 2026-09-30)
Telegram API Terms of Service (section 1.4, user consent) (accessed 2026-09-30)
Telegram API: Creating your Telegram Application (using the api_id) (accessed 2026-09-30)
Telegram FAQ: spam limits (accessed 2026-09-30)
Telegram blog: Silent Messages, Slow Mode (9 August 2019) (accessed 2026-09-30)
Telegram blog: bot-to-bot chats and Chat Automation (7 May 2026) (accessed 2026-09-30)
Telethon documentation: RPC errors and FloodWaitError (accessed 2026-09-30)
grammY: Scaling Up IV, flood limits (accessed 2026-09-30)

Originally published on the Dripl.ai blog.

Disclosure: this guide was generated with AI and checked against the sources listed above.

DEV Community: dripl_ai