How does a Telegram bot broadcast to subscribers actually work?
A Telegram bot broadcast to subscribers is a loop your own server runs: it reads the chat IDs of everyone who pressed Start, then calls sendMessage once per person. Telegram keeps no subscriber list for you and has no "send to all" method, so the list, the pacing and the cleanup all live in your code.
That surprises people who expect a button in BotFather. There is none. The Bot API is a set of single calls, and a broadcast is just many of them in a row, each to one chat. Everything that makes a broadcast work or fail follows from that: who got onto your list, how you stored them, how fast you send, and what you do when a call comes back with an error.
A bot is also only one of the ways to reach people at once on Telegram. If you are still choosing, our overview of how channel posts and broadcast lists reach people who already joined compares the options, and the page on bulk messaging services and the consent each channel expects covers email, SMS and WhatsApp next to Telegram.
Why can't a Telegram bot initiate a conversation with a user?
Because Telegram decided bots may only answer. The bot documentation says plainly that bots can't start conversations with users; a person has to message the bot first or add it to a group. Try to message anyone else and the API returns 403 with "Forbidden: bot can't initiate conversation with a user".
So the "telegram bot cannot initiate conversation with a user" error is not a bug or a limit you can raise. It is the rule working. The fix is upstream: give people a reason and a link to open the bot. These are the doors that put a person on a bot's list legally.
| Door | What the person does | What the bot may then send |
|---|---|---|
| Start button or deep link | Opens t.me/yourbot?start=source and taps Start | Private messages, until they block or delete the chat |
| Login Widget with write access | Signs in on your website and allows the bot to message them | Private messages, same as Start |
| Mini App write request | Accepts the write-access prompt inside your Mini App | Private messages, same as Start |
| Added to a group | A group admin adds the bot | Messages to that group only, never to its members one by one |
| Scraped or imported list | Nothing | Nothing: every send fails with 403 |
The last row is why a bot cannot be a cold outreach tool, however it is marketed. Products that send to strangers are logging in as user accounts instead, which is a different risk: read why bulk DMs from a personal Telegram account get limited before going near one. The same pattern shows up well beyond messaging. Software that fires actions in bulk at people who never opted in tends to be discounted by the platform, and this breakdown of what TikTok report bots really do and why volume fails walks through the moderation side of it.
The deep link's start parameter is worth using even on day one. A link like ?start=ig_bio arrives in the /start message, so you can save where each subscriber came from next to their chat ID and later see which post filled the list.
How should a bot store chat IDs for a broadcast?
Save the chat ID from every /start update in a table with one row per person, stored as a signed 64-bit integer, plus a status field. The Bot API warns that IDs can exceed 32 bits (up to 52 significant bits), so a 32-bit column silently corrupts them and those subscribers never receive a message.
The common search telegram bot store chat ids broadcast is usually asking two things: where to keep the IDs, and how to keep the list honest. Any database works, from SQLite for a small bot to Postgres for a large one. What matters is the shape of the row.
- chat_id as BIGINT, unique. Upsert on every /start so a returning user does not create a duplicate.
- status: active, blocked or gone. Only active rows get broadcasts.
- source: the deep-link parameter, if any.
- joined_at and last_seen, so you can tell a live list from an old one.
- language from the user object, if you send more than one version.
Keep the status current without guessing. When someone blocks the bot, Telegram sends a my_chat_member update with the new status "kicked"; when they unblock and press Start again, it flips back to "member". Handling that one update keeps the list clean between broadcasts. Store nothing you do not need: a chat ID, a first name and a source are enough to run a broadcast, and a short list of fields is easier to protect and to delete on request. Add a /stop command that sets the row to inactive, and honor it at once.
How do you send a message to all users of a bot without hitting limits?
Read the active rows, send one message per chat at no more than about 30 per second, and handle every error as it comes back. That is the whole answer to "telegram bot send message to all users": a paced queue, not a single call. Telegram's FAQ also asks for no more than one message per second in a single chat.
Here is how to broadcast message to all bot users in the order we build it for clients.
- Freeze the audience. Copy the active chat IDs into a broadcast job table with a pending flag, so new subscribers mid-send do not shift the queue and a crash can resume where it stopped.
- Prepare the message once. Upload any photo or video in a test send first and reuse the returned file_id, so the server is not uploading the same file thousands of times.
- Send in paced batches. A worker takes 25 to 30 pending rows per second and calls sendMessage (or sendPhoto, or copyMessage from a draft chat) for each. Staying a little under the ceiling leaves room for retries.
- Record every result. Mark each row sent, failed or retry. A 403 changes the subscriber's status; a 429 pauses the worker.
- Report at the end. Delivered, blocked, gone and still pending. That last number should be zero before you call the job finished.
Two habits save the most trouble. Send the broadcast to a test chat first, every time, because there is no recall once it goes out. And keep the copy short with one clear button; a long wall of text from a bot gets muted, and a muted bot is one step from a blocked one. For wording, our cold message templates rewritten line by line apply just as well to a first broadcast, and for timing and offers the DM marketing guide with its worked Telegram numbers shows how often a list tolerates hearing from you.
What do broadcast errors mean, and what should the bot do with each?
Most failures in a broadcast are 403s from people who left, plus 429s when you send too fast. Treat 403 as a status change and 429 as an instruction to wait the exact number of seconds Telegram returns in retry_after. Retrying a 403, or ignoring a 429, is what turns a routine send into a slow, error-filled one.
| Response | What it means | What the bot should do |
|---|---|---|
| 403: bot was blocked by the user | They blocked the bot | Set status blocked; skip until a new /start |
| 403: user is deactivated | The account was deleted | Set status gone; drop the row from future sends |
| 403: bot can't initiate conversation with a user | This ID never started the bot | Remove it; find how it got onto the list |
| 400: chat not found | Wrong or corrupted ID (often a 32-bit column) | Check the stored value, then remove if it is bad |
| 429: Too Many Requests, retry after N | You exceeded the pace | Pause the worker N seconds, resend the same row |
A healthy list loses a slice of its rows to blocks with every broadcast, and that is normal. What is not normal is a sudden jump in blocks right after a send, which tells you the message, not the code, was the problem. If you are deciding which parts of a campaign a script should run and which a person should, our notes on which outreach steps are safe to automate and what the stack costs draw that line for email and DMs too.
How long does a Telegram broadcast take?
At the free ceiling of about 30 messages per second, a bot reaches 10,000 subscribers in roughly 6 minutes and 100,000 in roughly 56 minutes. Paid broadcasts raise the ceiling to 1,000 per second, but they cost Stars and need a large bot. Telegram itself suggests spreading free broadcasts over 8 to 12 hours.
So the honest answer to "how long does a telegram broadcast take" depends on list size and on whether you want speed or spread. The figures below are the floor at full pace; real jobs run a little slower because of retries and media.
| Active subscribers | Free, 30 per second | Paid, 1,000 per second | Paid cost (approx.) |
|---|---|---|---|
| 1,000 | About 34 seconds | Not worth it | None |
| 10,000 | About 6 minutes | Not worth it | None |
| 100,000 | About 56 minutes | About 100 seconds | About 9,700 Stars |
| 500,000 | About 4 hours 38 minutes | About 8 minutes 20 seconds | About 48,500 Stars |
| 1,000,000 | About 9 hours 16 minutes | About 17 minutes | About 97,000 Stars |
The cost column follows Telegram's rule that each message above the free 30 per second costs 0.1 Stars. At 100,000 users and full paid speed, about 3,000 messages fit inside the free rate during those 100 seconds, and the other 97,000 cost 0.1 Stars each. Paid broadcasting is switched on per message with the allow_paid_broadcast parameter, and the FAQ sets two entry conditions: at least 100,000 Stars on the bot's balance and at least 100,000 monthly active users.
Should you broadcast fast or slow?
Fast only when the message is time-bound: a live stream starting, a sale ending, an outage. For everything else, slow wins. A send spread over ten hours means a 100,000-user bot sends fewer than three messages a second, never meets a 429, and lands while people in different time zones are awake. It also means your support chat gets replies at a pace a person can answer. For volume figures on other Telegram tools, see the limits a Telegram message sender runs under.
When is a channel post better than a bot broadcast?
When the message is one-way and identical for everyone. A channel post reaches every subscriber at once, with no rate limit, no loop and no server, and readers can mute it without blocking anything. A bot broadcast earns its extra work when you need personal fields, segments, buttons that run actions, or a reply flow.
Many of our clients end up running both: a channel for news, and a bot for the parts that need one person at a time, such as orders, reminders and support. If your audience is a group rather than a channel, the plain explainer on what adding people to a Telegram group in bulk really allows covers the limits there, and for a single message to one person, every way one person can message another on Telegram is the place to start.
A case from August shows why the stored list matters more than the sending code. A course creator came to us with a bot of about 40,000 subscribers whose broadcasts "reached nobody". The sending loop was fine. The chat IDs had been saved in a 32-bit integer column two years earlier, so every user with a larger ID came back as "chat not found". We migrated the column to BIGINT, rebuilt the active list from fresh /start events plus a channel post asking people to tap Start again, and moved sends to a ten-hour spread. The next broadcast reached the rebuilt list with a few hundred 403s from people who had genuinely left, which is what a working broadcast looks like.
Bots are one piece of outreach, not the whole of it. If you are planning the wider program, read how we plan a cold outreach program and read its reply rates, the seven outreach types and where a bot fits among them, and our page on comment triggers and the DM automation platforms allow, which is where most bot subscribers come from in the first place.