Broadcasting to Thousands Without Getting Blocked

What Telegram actually limits and why

Telegram's bot platform is built to protect the person receiving the message, not the person sending it. That design decision explains every limit you will run into. There are three separate families of restriction, and confusing them is the most common reason a send goes wrong.

• Mechanical rate caps — how many API calls per second you may make, in total and per chat. These fail loudly and are fully recoverable.
• Per-recipient state — the user blocked the bot, deleted their account, or the chat no longer exists. These fail permanently for that one recipient.
• Reputation effects — users reporting, blocking or muting your bot in numbers. These do not produce an error at all. They show up as a slow decline in the results of every future send.

Engineering fixes the first family. Nothing but editorial discipline fixes the third. Most teams that get burned spend all their effort on retry logic and none on cadence.

Rate limits, retries and queueing basics

Telegram documents a broad ceiling around 30 messages per second spread across different chats, and roughly one message per second to the same chat. Groups are tighter still. These are soft ceilings: the platform can quietly narrow them for a bot that produces reports or sends in aggressive bursts, so build for a pace comfortably under the published number rather than pinned to it.

When you exceed a cap, the API answers with 429 Too Many Requests and a retry_after value in seconds. The only correct response is to stop that worker for exactly that long and resume in order. Retrying straight away, or fanning the same queue out across more workers to dodge the wait, extends the throttle and can escalate it into something longer-lived.

A sane sending queue has four properties. One ordered queue per bot, so two operators cannot start overlapping sends. A token bucket that paces below the ceiling. A hard split between transient failures (network errors, 5xx, 429) which are retried a bounded number of times, and terminal failures (the user blocked the bot, the chat is gone) which are never retried. And a stored per-recipient result, so a resumed or repeated send does not deliver twice.

That classification step matters more than the pacing. A queue that keeps retrying 403 responses will spend hours hammering people who already left, while the subscribers who are still with you wait at the back of the line. mySkua runs broadcasts server-side with bounded retries, and drops subscribers who have blocked the bot instead of retrying them forever — see how broadcasts work.

The difference between a block and a mute

A block is loud. The user taps Block, and every subsequent send to that chat returns a 403 error saying the bot was blocked. You can count blocks, chart them, and act on them. They are also honest: the person has told you to stop, and the only correct handling is to mark them and stop.

A mute is silent, and far more dangerous. The chat stays in the user's list, your message is still accepted, and it still counts as delivered — it simply never makes a sound. Nothing in the API tells you it happened. A heavily muted list looks perfect on a delivery report and produces almost nothing.

This is why delivery rate on its own is a lying metric for a broadcast message. The signal that catches mutes is engagement measured against delivery: inline-button clicks and campaign activations. When deliveries stay flat while clicks fall away over consecutive sends, you are being muted, and that is the leading indicator of subscriber churn — the blocks arrive weeks later.

Frequency rules that keep lists alive

There is no universal safe cadence, because tolerance is set at opt-in. Someone who joined for a specific promo code expects a promo code, not a daily newsletter. Three rules travel well across funnels:

• Name the payoff before you send. If you cannot state in one sentence what this message gives the recipient, it is a mute risk, not a broadcast.
• Budget bulk sends separately from automation. Drip messages triggered by joining, and offers triggered by a deep link, are expected. Untargeted blasts are the ones that accumulate resentment, so cap those specifically.
• Spend the honeymoon early. The days right after someone joins are your highest-tolerance window. A timed sequence there does more work than a fourth weekly blast ever will.

Repetition is the quiet killer. Re-sending an offer to people who already claimed it reads as carelessness. Campaigns in mySkua activate once per subscriber, so a claimed offer stops following that person around.

Segmenting instead of blasting everyone

Every irrelevant message spends attention you cannot get back, and the whole-list blast is the most expensive way to spend it. Segmenting is not only a relevance tactic — it is also a limits tactic, because a send to four thousand targeted subscribers finishes well inside the rate ceiling while a send to forty thousand does not.

The dimensions worth using are the ones you already collect during onboarding: language chosen at /start, the category the subscriber picked for themselves, the source recorded from the deep-link payload, and tags applied along the way. A subscriber who selected Sport should not receive a casino offer. A subscriber who arrived through an Instagram deep link should get copy that matches the creative they clicked, because they remember it. Auto-messages and broadcasts can both be aimed at those attributes rather than at everyone.

Segmented sends also make results readable. When one message goes to one audience, a drop in activations tells you something specific. When one message goes to the whole list, it tells you nothing you can act on.

Timing sends across time zones

A single 09:00 broadcast is 09:00 in exactly one place. If your list spans Lisbon, Budapest and Manila, one send time means somebody is being woken up — and a notification at 03:00 buys you a mute at best. Language is a reasonable proxy for region when you have nothing better, and it is a dimension you already store.

Two practical habits: schedule recurring broadcasts per timezone rather than in server time, so daily and weekly sends land in the reader's morning and stay put through daylight-saving shifts; and avoid the exact top of the hour, where every automated marketing system on the planet is already queued. Staggering regional sends across the hour also spreads your own API traffic, which keeps you further from the rate ceiling on a large list.

Reading delivery stats to catch problems early

Check these immediately after each send, not once a month, because the useful comparison is send-over-send:

• Attempted vs delivered vs failed, with failures broken down by reason. A steady baseline of blocks is normal; a rising share is a warning.
• Clicks and campaign activations against delivery. Flat delivery with falling engagement is the mute signature described above.
• Retention cohorts by join week. If a cadence change hurt, the cohorts that joined after it will decay faster than the ones before it. This is the cleanest evidence you will get that you are sending too much.
• Net growth, not gross. New subscribers minus blocked and inactive ones. A funnel adding two thousand people a month while burning eighteen hundred is not growing, it is churning.

Recovering a list you have already over-mailed

Recovery starts with silence. Nothing improves while the volume that caused the problem continues, so stop broadcasting for a defined pause — long enough that your next message is a small surprise rather than more of the same. Then restart deliberately:

• Come back to the segment that still engages, not to everyone. The unresponsive remainder can wait.
• Make the return message your strongest piece of content, not a housekeeping note.
• Re-set expectations in one short message: what you will send, how often, and an inline button to choose a category. People who choose their own topic mute far less.
• Rebuild targeting from behaviour — recent activations, category, language, source — so the next month of sending is narrow by construction.
• Accept the shrinkage. A smaller list that opens you outperforms a large muted one, and the vanity number was never the asset.

Common questions

How many messages per second can a Telegram bot send?

Roughly 30 per second across different chats, and about one per second to the same chat, as a documented soft ceiling. Pace under it rather than at it, since the platform can narrow the limit for bots that attract reports.

What happens when a bot hits a rate limit?

You receive 429 Too Many Requests with a retry_after value. Wait exactly that long, then resume in order. Do not retry immediately and do not add workers to route around the wait.

Does Telegram tell you when someone mutes your bot?

No. Mutes are invisible and the message still counts as delivered. Infer them from engagement falling while delivery stays flat.

How often can you broadcast without losing subscribers?

As often as you can name a concrete payoff for the recipient. Automation timed to the subscriber's own lifecycle sustains a far higher frequency than repeated blasts to the whole list.

Doing this without hand-rolling the queue

Most of the work above is infrastructure: paced sending with bounded retries, terminal errors separated from transient ones, blocked subscribers dropped automatically, recurring sends scheduled per timezone, drips targeted by language, category, source or tag, and delivery plus activation data sitting next to retention cohorts so you can see damage while it is still small.

That is what mySkua does for Telegram lead-generation bots, with each bot keeping its own subscribers, content and team. The platform is currently in invite-only private beta — if you run Telegram funnels and want to try it, join the waitlist and request access, and we will get in touch.