Около 30 сообщений в секунду — так Telegram описывает бесплатный предел массовых уведомлений в своём FAQ. Число выглядит приглашением нажать кнопку посильнее. А я бы начал с противоположного вопроса: умеет ли программа остановиться, когда её просят подождать? Скорость можно обсуждать после этого.
В той же документации Telegram ограничения разделены. В одном чате рекомендуют избегать отправки чаще одного сообщения в секунду; для группы указан предел 20 сообщений в минуту. Массовая отправка имеет свой порог. Значит, общая скорость ещё не говорит, как часто можно писать одному получателю. Проверено по официальной странице на день публикации, 7 ноября 2026 года.
У превышения есть номер — 429. В API предусмотрен необязательный параметр retry_after, который при ограничении частоты сообщает, сколько секунд надо выждать перед повтором запроса. Для человека это неприглядное техническое название. Для программы — вполне содержательная просьба сделать паузу. Если параметр пришёл, я советую учитывать указанное ожидание, а не повторять неудачную отправку немедленно.
Пауза тоже работа.
За словом «рассылка» я предлагаю видеть очередь отдельных отправлений. У каждого есть получатель, текст и состояние. Такая модель нужна ещё до выбора оформления кнопки администратора: она позволяет понять, какая часть задания закончена, какая ждёт и к чему возвращаться после остановки. Без этого зелёное сообщение об успешном запуске легко принять за завершение всей работы.
Я бы разделял запуск и завершение прямо в интерфейсе. Сначала программа принимает задание, затем показывает ход выполнения, а в конце выдаёт отчёт. Это предложение к устройству будущего бота, а не описание функции, которую я проверил в каждом готовом проекте. Разница в надписях кажется мелочью, пока владелец не закрывает Telegram с уверенностью, что всё уже отправлено.
В очереди полезно хранить результат для каждого адресата. Успешный ответ на отправку, известная ошибка, ожидание повтора — разные исходы, и смешивать их в одно слово «обработано» я не советую. Когда нужна помощь разработчика, такая запись объяснит, на каком шаге возник вопрос. Сплошная итоговая цифра заставляет заново разбирать весь запуск, включая то, что уже закончилось нормально.
С повтором сложнее, чем с первым сообщением. Если просто начать задание заново, прежний успех можно не учесть — поэтому прогресс стоит сохранять. Но даже сохранённая очередь не обещает безупречной доставки: если связь оборвалась после того, как запрос ушёл, и программа не получила ответа, разработчику придётся разбираться, дошло ли отправление, прежде чем решать, надо ли пробовать снова. Я предпочёл бы увидеть в отчёте такое незавершённое дело, чем красивую отметку об успехе, которую программа на самом деле не может подтвердить.
Рядом с кнопкой запуска я бы хотел видеть способ остановить оставшуюся очередь. Не стереть уже сделанное, а прекратить новые попытки и сохранить понятный отчёт. Владелец может заметить ошибку в тексте после старта. Исправленный вариант тогда должен обсуждаться как новое действие, а не незаметно подменять старое посреди отправки. Иначе впоследствии трудно объяснить, кому досталась какая редакция.
Перед запуском полезен и отдельный просмотр сообщения. Ссылки, абзацы, обращение к получателю лучше оценивать на тестовом адресате, без настоящей массовой отправки. Я рекомендую делать предпросмотр отличимым от рабочего запуска, чтобы проверка оформления не становилась командой всем пользователям. Тут достаточно ясного названия действия; прятать смысл за одинаковыми кнопками не стоит.
У очереди есть ещё одно измерение — содержание. Напоминание о выбранном человеком действии и предложение купить что-нибудь ещё я бы не объединял в один поток без обсуждения. Для них могут понадобиться разные настройки получателей и отказа от сообщений. Технический предел Telegram не отвечает на вопрос, согласился ли человек на рекламу, и я не предлагаю считать соблюдение скорости таким согласием.
Не знаю, какая частота подойдёт вашему сценарию, пока не понятен повод сообщения. Уведомление об изменении записи устаревает иначе, чем объявление о новой услуге. До разработки стоит назвать срок, после которого отправлять уже бессмысленно. Тогда в очереди появляется правило отмены: оставшееся задание лучше снять, чем аккуратно доставить устаревший текст. Я бы заранее согласовал, кто вправе принять такое решение и как его увидит администратор. Остановка по истечении срока должна быть отличима от сбоя — иначе владелец примет предусмотренное поведение за поломку и начнёт отправку заново.
В FAQ есть платный способ повысить скорость массовых отправок. Я не стал бы начинать маленький проект с его подключения, не выяснив, требуется ли вообще такой темп. Возможность платить за скорость не решает вопросы повтора, остановки и содержания. (Зато обсуждать её легче: у неё есть название.) Для начала полезнее разобраться с тем, что программа делает при обычной задержке.
При заказе бота под свою задачу я советую описать ожидаемый результат словами владельца. Кто должен получить сообщение, откуда берётся этот список, какой текст надо показать перед запуском и что считать завершением. Такие договорённости переводятся в проверяемые действия без большого технического задания. Очередь можно проверить на тестовых получателях, ошибку — воспроизвести отдельно, остановку — увидеть, а не принять на веру.
Отчёт при этом лучше называть буквально. Успешная отправка не означает, что человек прочёл сообщение и согласился с ним. Если в проекте нужен ответ получателя, его стоит предусмотреть отдельным действием — например, подтверждением кнопкой. Я не советую заменять это предположением о прочтении: иначе аккуратная статистика начнёт отвечать на вопрос, которого ей не задавали.
Администратору не обязательно разбираться в названии retry_after. Ему нужен понятный экран: отправка ждёт разрешённого повтора, результаты уже выполненной части сохранены, работу можно остановить. Техническое слово пусть останется в записи для разработчика. Рядом с ним — число секунд до следующей попытки.