Running it

Telegram bot rate limits and how to stay inside them

By the Botable team

Telegram enforces soft limits on how fast a bot can send: roughly one message per second to a single chat, a higher ceiling overall, and a lower one for bulk sends to a group. Exceeding them gets you throttled with a retry delay, not banned.

The short version

Telegram applies rate limits to bot sends, and the documented guidance is that a bot should not exceed roughly one message per second to any single chat, with a higher aggregate ceiling across all chats and a notably lower allowance for repeated messages into the same group. These are described as soft limits: brief bursts are usually tolerated, sustained excess is not. When you cross the line Telegram responds with a too-many-requests error carrying a retry-after value, which a correct client honours by waiting exactly that long rather than retrying immediately — retrying at once extends the penalty. The practical consequence is that any bot doing bulk sending needs a queue with pacing built in rather than a loop over a recipient list. Broadcasting to a few thousand users is a job measured in minutes, and treating it as an instant operation is the single most common way bots get throttled.

Step by step

What are the limits in practice?

Telegram's guidance is about one message per second to an individual chat, a higher overall ceiling across all chats, and a stricter cap on repeated messages into the same group. Treat these as the documented soft limits they are and check the current Bot API FAQ rather than hardcoding a number from memory.

What happens when you exceed them?

You get a 429 with a retry-after value. Nothing is lost permanently and the bot is not banned, but every send in that window fails. Honour the retry-after exactly; retrying sooner is treated as continued excess and lengthens the wait.

How should bulk sends be structured?

As a paced queue, not a loop. Space sends to stay under the per-chat and aggregate ceilings, persist progress so a crash resumes rather than restarts, and expect a broadcast to a large audience to take minutes. Instant delivery to everyone is not an option the platform offers.

How do you reduce the number of sends at all?

Edit instead of re-sending for anything that updates, batch several facts into one message rather than sending three, and drop recipients who have blocked the bot as soon as the error tells you so. The cheapest way through a rate limit is needing fewer requests.

What catches people out

  • Retrying immediately after a 429 extends the penalty rather than clearing it
  • Group sends have a stricter limit than private chats — a broadcast tuned for DMs will trip it
  • Users who blocked the bot still consume a request; prune them or you pay for them forever

Questions

Can the limits be raised?

Telegram has historically discussed higher allowances for large bots, but plan for the documented limits. A design that only works with an exception is a design that breaks the day the exception does not apply.

Do limits apply to receiving messages?

The constraints are on outbound sends. A busy bot receives whatever arrives; the throttling applies to what it sends back, which is why a viral moment shows up as slow replies rather than missed messages.

Want a bot that does this?

Describe it in plain language and Botable writes the code, gives the bot its own database, deploys it and keeps it running. Everything on this page is handled for you — the token, the webhook, the storage, the hosting.

Build a bot

Keep reading

Bots that use this

All twenty-five guides