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

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.

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

1. 1

   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.

2. 2

   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.

3. 3

   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.

4. 4

   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.

5. 5

   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.

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.

Some scheduling tools offer these as presets. You can see how per-account pacing profiles set caps, a gap and jitter together, and pick the conservative one when you aren’t sure.

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.

Where a scheduling tool fits

A tool that sends for you should do what this guide describes: respect the wait, space messages out and show you what happened. Here is what Dripl does today, so you can judge it against that list.

Dripl’s scheduler sits out a wait of up to a minute, then sends the message. For a longer wait, Dripl notes it in the account’s health, pauses a minute and tries once more, sitting out up to one more minute. If Telegram’s wait still has longer to run, the message fails with Telegram’s error, and you can retry it from the Errors page once the wait is over.

In forwarding rules, a longer wait fails that copy straight away, logged with Telegram’s error, and the wait shows in the account’s health. A retry from the log sends the post’s text only.

Each account in Dripl keeps its own daily and hourly caps and waits a minimum gap between messages, for scheduled messages and forwarding alike; scheduled messages also get a little random jitter, and forwards get it when they have to wait for the gap. Forwarding can also give each destination an hourly cap and a delay, so several channels don’t all post in the same second. None of this keeps an account inside Telegram’s limits, which Telegram doesn’t publish for user accounts; conservative caps simply leave the most room.

• Multi-account

  Connect several Telegram accounts with a QR code, give each its own sending pace and proxy, and see at a glance which ones need you.

  Learn more

• Scheduler

  Send one-off and recurring messages to Telegram contacts, groups and channels at the time and in the timezone you choose, with templates and attachments.

  Learn more