GLOSSARY

What is a Flood Wait?

A flood wait is Telegram's MTProto rate-limit response: an error of the form FLOOD_WAIT_X (where X is seconds) telling the client to back off and retry after the specified delay. Ignoring it can escalate from short waits to account restrictions and bans.

Try CRM Solid free See live demo

14-day free trial · No credit card required · Cancel anytime

Quick definition

A flood wait is Telegram's MTProto rate-limit response: an error of the form FLOOD_WAIT_X (where X is seconds) telling the client to back off and retry after the specified delay. Ignoring it can escalate from short waits to account restrictions and bans.

In a single sentence: "wait X seconds before talking to me again, or things will get worse".

What it means

A flood wait is the way Telegram's MTProto servers tell a client: "you are doing too much, slow down". It is a structured error response with a single integer payload: the number of seconds the client must wait before making the same call again.

Telegram's rate-limiting system is intentionally opaque. You do not get a public quota table; you get a runtime signal when you cross a threshold. That makes flood waits a feedback loop, not a configuration: every client has to actively listen for them, respect them, and adapt the send rate based on what it observes.

Important nuance: flood waits are per-account, per-method. Hitting a flood wait on messages.sendMessage does not block calls to messages.getHistory. And a flood wait on one account does not block other accounts in your pool. This is why account rotation works, but only when combined with pacing.

The FLOOD_WAIT_X error format

The error string is literal: FLOOD_WAIT_X, where X is the number of seconds. So FLOOD_WAIT_30 means "wait 30 seconds"; FLOOD_WAIT_3600 means "wait 1 hour"; FLOOD_WAIT_86400 means "wait 24 hours".

On the wire, the error arrives as an RPC error with type rpc_error, error code 420, and an error message of the form FLOOD_WAIT_X. Most MTProto client libraries parse the X out for you and either expose it as structured data or convert the error into an exception with the wait time attached.

Related but distinct errors:

SLOWMODE_WAIT_X: chat-level slowmode, not account-level. Triggered when a group has slow-mode enabled.
FLOOD_PREMIUM_WAIT_X: premium-feature-specific limit (e.g., reactions). Behaves like a flood wait but only applies to the specific feature.
PEER_FLOOD: a more serious version with no X. The account is restricted from sending to non-contacts entirely; only un-restricted by support contact or a long cooldown.

PEER_FLOOD is the one to fear. It means Telegram has decided your account looks like a spammer and is throttling cold-DM behavior with no automatic recovery. Treat any PEER_FLOOD as a stop-and-investigate event.

How clients should back off

The reference behavior is:

Sleep for at least X seconds. Not X minus two, not "estimated X"; use exactly what the server said, plus a small safety margin (5-10%).
Retry the original call. Most flood waits are transient; the same call usually succeeds after the wait.
If the retry hits another flood wait, double the safety margin and consider applying an exponential back-off across the whole sending pipeline, not just the individual call.
If X is greater than 3600 seconds (1 hour), stop sending from this account entirely for the day. Long flood waits are a leading indicator of escalation to PEER_FLOOD or full restriction.

A naive exponential back-off can look like this:

attempt 1 sleeps X seconds, attempt 2 sleeps X × 2, attempt 3 sleeps X × 4. Cap the multiplier so you do not end up sleeping for 18 hours after a bad day.

What you must not do: ignore the wait, switch to a different account immediately and keep hammering, or retry inside the wait window. All three escalate the issue from "this account paused" to "this account flagged".

Why it matters

For low-volume Telegram CRMs, flood waits are an occasional inconvenience. For anyone doing real outbound (100+ DMs per account per day), flood waits are the central operational challenge.

The economic impact is direct. Without proper handling, a single account hitting cascading flood waits during a bulk send can stall an entire campaign. With proper handling (account rotation, paced sending, exponential back-off, warm-up), the same account can run for months without escalating to a ban.

Flood waits also predict bans. Telegram's restriction escalation is roughly: minor flood waits → larger flood waits → PEER_FLOOD → spam-block → permanent restriction. Catching the pattern early, and slowing down, is the only way to avoid the later stages.

Real-world examples

SDR sending 200 DMs/hour from one account. First flood wait at minute 12: FLOOD_WAIT_30. Second at minute 25: FLOOD_WAIT_60. By minute 45 the waits climb to 5 minutes. If the client ignores them, by hour 2 the account is in PEER_FLOOD and effectively offline for 48 hours.
Bulk-import via group scraping. Scraping member lists from large public groups can trigger flood waits on channels.getParticipants. Standard handling: page through with 100-member chunks and a 1-second pause between pages.
Mass account creation. account.sendCode has a particularly aggressive limit. Trying to register 50 numbers in an hour will trigger flood waits in the thousands of seconds.
Joining many groups at once. channels.joinChannel has a per-account limit of roughly 200 joins per day. Crossing that throws aFLOOD_WAIT of about 24 hours.
Account warming. A freshly-created account that sends a DM in the first 24 hours almost always hits a flood wait. Warm-up (a few days of receiving messages, joining channels, posting in groups) dramatically reduces flood-wait frequency.

Common mistakes

Treating flood waits as fatal errors. They are not; they are throttling signals. Logging them as errors and stopping the campaign loses you the entire send window.
Hot-switching accounts on every flood wait. If account A hits a wait, immediately switching to account B at the same send rate just produces a wait on B in 10 minutes. Slow down across the pool, not just within the account.
Not exponentially backing off. Sleeping for exactly X and retrying, over and over, produces the same pattern that triggered the wait in the first place. Double the safety margin on each retry.
Ignoring PEER_FLOOD as if it were a normal flood wait. It is not. PEER_FLOOD requires a full stop, a 24-hour cooldown, and a behavior change, not a 5-minute pause.
Skipping account warm-up. A fresh number has zero trust signal. Treat the first 7 days as warm-up-only: receive messages, browse groups, do not send cold outbound at all.

Related concepts

MTProto: the protocol that defines and enforces flood waits.
Spintax: reduces duplicate-content signals that contribute to rate-limit escalation.
Cold outreach: the workflow that hits flood waits most often.
Drip campaign: the pacing structure that, when designed right, never hits flood waits at all.
Webhook: flood waits should fire a webhook into your ops monitoring so the team can adjust pacing in real time.
Omnichannel CRM Needs flood-wait awareness baked into every send path, not just Telegram.

How CRM Solid handles it

CRM Solid's send engine parses every MTProto response and auto-handles FLOOD_WAIT_X with an exponential back-off curve tuned across thousands of accounts. Long waits (above 1 hour) automatically pause the account for the rest of the day; PEER_FLOOD halts the account and notifies the operator. Account rotation respects per-account waits, so one account hitting a 5-minute pause does not stop the campaign. The rate limiter is configurable in appsettings.json. Twenty messages/hour and 50/day per account are our production defaults.

Cheat sheet · what the error looks like

Anatomy of a FLOOD_WAIT response.

The exact JSON-ish shape varies by MTProto client library (these are the canonical fields).

{
  "_": "rpc_error",
  "error_code": 420,
  "error_message": "FLOOD_WAIT_30",
  "method": "messages.sendMessage",
  "phone": "+15551234567"
}

// Pseudo-code: the canonical handler
async function sendWithBackoff(call) {
  let attempt = 0;
  while (true) {
    try {
      return await call();
    } catch (e) {
      if (e.code !== 420) throw e;
      const seconds = parseFloodWait(e.message);
      const margin = 1 + Math.min(0.5, 0.1 * attempt);
      await sleep((seconds * margin) * 1000);
      attempt += 1;
      if (attempt > 3 || seconds > 3600) {
        markAccountForCooldown(call.account, '24h');
        throw new AccountPausedError(call.account, seconds);
      }
    }
  }
}

Minor waits

FLOOD_WAIT_1 to FLOOD_WAIT_60: routine. Wait and retry.

Medium waits

FLOOD_WAIT_300 to FLOOD_WAIT_3600: slow down systematically.

Long waits

FLOOD_WAIT_86400 or PEER_FLOOD: stop the account, investigate.

Safe-send checklist

Six rules that almost-never produce a flood wait.

Warm each account for at least 7 days before sending cold outbound.
Cap each account at 20 DMs per hour and 50 per day to fresh contacts.
Keep at least 10 seconds between any two sends from the same account.
Rotate across at least three accounts for any campaign over 100 sends.
Apply exponential back-off to every retry, not linear.
Pause an account for 24 hours after any FLOOD_WAIT longer than one hour.

“Once we wired auto-FLOOD_WAIT handling into our send loop, our account-survival rate for 30-day campaigns went from 60% to 94%. Same volume, fewer babysitting hours.”

Tomás Vega

Head of Platform · DM Engine

Flood waits: FAQ

Operational questions every Telegram CRM operator hits within their first month.

Sending too many messages too fast, joining or leaving too many groups in a short window, mass-following users, or hitting any per-method limit Telegram silently enforces. The thresholds are not publicly documented; they're tuned dynamically against signals like account age, recent ban history, and what looks like coordinated behavior.

For low-volume accounts, yes. Stay under 20 DMs per hour to fresh contacts and you will essentially never see one. For bulk outreach, no. You should design assuming you WILL hit them, and treat the back-off as a normal control loop instead of an error.

From 1 second to 24 hours, depending on the severity. Common ranges: 5-30 seconds for minor rate-limit hits, 5-15 minutes for sustained over-sending, 1-6 hours for aggressive bulk behavior, and 24 hours or longer for repeat offenders. Anything over an hour is a strong signal to slow down systematically, not just wait it out.

No. It is a soft limit, not a ban. The account remains functional and the wait clears automatically. But chronic flood waits are the leading indicator of an upcoming spam-block or full ban, so they should be treated as a warning.

Rotation is part of the answer, but rotation alone, without paced sending and warm accounts, just produces the same flood waits across many accounts simultaneously. The real solution is to combine rotation, pacing, account warm-up, and exponential back-off into one safe-send pipeline.

Yes. The Bot API enforces its own limits (about 30 messages/second to different users, 1/second per chat, lower for groups). The error responses are different in format but behave the same way: respect the suggested retry-after and the account stays healthy.

Keep reading

MTProto

The Telegram protocol that defines flood waits.

Spintax

Cuts the duplicate-content signal that contributes to rate limiting.

Cold outreach

The workflow that hits flood waits most often.

Avoid Telegram bans

A 30-day warm-up protocol that keeps accounts alive.

Bulk messaging best practices

Production-tested pacing and rotation for safe bulk DMs.

Ready to ship

Handle flood waits automatically.

CRM Solid auto-backs-off on FLOOD_WAIT, rotates accounts, and pauses senders before they get banned. Sleep better.

Start free trial Talk to sales

Trusted by 2,500+ teams · GDPR-ready · 99.95% uptime