Telegram-бот перестал отвечать: проверяют токен, доставку события и выполнение бизнес-действия

Бот молчит у всех или только на кнопке оплаты? Для инженера это разные задачи. Сохраните время сбоя и последний успешный заказ.

Проверьте путь клиента целиком. Личный чат, кнопка заказа и выдача доступа могут проходить через разные части приложения.

Тест на /start проверяет приветствие. Он не доказывает, что менеджер получил заявку или покупатель вошёл в оплаченный канал.

Здесь речь о ремонте существующей системы. Выбор сценария нового бота разобран в статье про разработку Telegram-бота.

Токен открывает приложению доступ к боту. Инженер проверяет его методом getMe из документации Telegram и сверяет, что ответил нужный бот.

Проверять нужно ключ, который использует работающая версия приложения. Ключ на компьютере разработчика может отличаться от того, с которым запущен бот.

Успех getMe подтверждает ключ. Сетевой тайм-аут оставляет вопрос открытым: приложение могло не достучаться до Telegram.

Отозванный ключ заменяют в работающей системе. Перевыпуск токена без этой замены оставит бота молчать; сам ключ в переписку и отчёт не вставляют.

Бот получает события одним из двух способов. Telegram сам присылает их приложению через webhook, либо приложение забирает их методом getUpdates.

Эти режимы несовместимы. По документации Telegram, включённый webhook не позволяет получать события через getUpdates. После переезда сверяют выбранный режим и адрес доставки.

При webhook инженер смотрит getWebhookInfo: адрес, очередь и последнюю ошибку. Затем ищет контрольное событие в журнале приложения; пустая очередь ещё не означает выполненный заказ.

Входящие события Telegram хранит не дольше 24 часов до получения ботом. Это лимит очереди, а не время, за которое подрядчик обещает починку.

Бот получил нажатие, но что сделал дальше? Для заказа нужны запись и передача менеджеру. Для доступа нужны подтверждённая оплата и возможность войти.

Например, при проверке выдачи доступа смотрят подтверждение оплаты, запись права и вход тестового покупателя. Сообщение «доступ открыт» не заменяет ни одну из этих проверок.

Заказ сверяют по одному номеру на всём пути. Если бот отправил «принято», а записи в системе компании нет, сквозной сценарий не пройден.

Повтор события проверяют отдельно. Telegram повторяет неуспешную доставку webhook; обработчик должен узнать уже выполненное действие и не создать второй заказ.

После починки нужен сигнал о повторной остановке. Проверка «процесс запущен» пропустит ошибку записи заказа, если приложение продолжает работать.

Инженер ведёт машину агентов на vibecoding.ru; её открытый журнал работы показывает выпуск изменений. Опыт этой машины включает остановку новостного автомата.

Лента ниже показывает этапы одного инцидента. Это аналогия с ботом: Telegram тогда не ремонтировали. Правило получилось из несовпадения видимого прогресса и результата.

Для вашего бота проверка должна сопоставлять вход и выход: контрольное событие пришло, заказ появился или доступ выдан. При отсутствии результата она зовёт ответственного.

Задача «бот не работает» оставляет агенту угадывание. Нужны действие клиента, ожидаемый результат и место, где он исчез; это тот же принцип постановки задачи агенту.

Агент может найти обработчик, воспроизвести ошибку на тестовых данных и подготовить исправление с проверкой. Инженер принимает изменение и ведёт его до проверки рабочего сценария.

Диагностике хватает номера события и обезличенной ошибки. Работа с данными клиентов требует отдельной границы: переписку покупателей целиком агенту не передают.

Повтор реальной оплаты или массовую выдачу доступа не включают в ремонт автоматически. Ответственность за поломку и разрешение на такие действия заранее остаются за людьми.

Оплата ремонта зависит от того, кто управляет сломавшимся шагом. Код собственного бота можно исправлять в вашем репозитории; сбой Telegram или настройки чужого конструктора оценивают отдельно.

На /services тариф «Один проект» стоит 250 000 ₽ в месяц, проверено 8 октября 2026. Это один поток разработки с очередью, а не отдельная цена за перезапуск бота.

Подписка на разработку имеет смысл, если после восстановления нужны новые сценарии, интеграции и проверки. Разовую замену ключа сначала оценивают как отдельную задачу.

Срок восстановления называют после диагноза. Чистая очередь событий и запущенный процесс не дают оснований обещать, что все пропущенные заказы вернутся.

Если ремонт некому вести, тест для руководителя поможет оценить устройство разработки в компании. Для обсуждения бота подготовьте симптом и ожидаемый бизнес-результат.

Ночные дежурства в подписку не входят. Если бот принимает заказы круглосуточно, заранее назначьте того, кто получит сигнал и примет решение при остановке.

1. Начните с места остановки: ключ, доставка события, обработчик, заказ или доступ.

2. Проверяйте бизнес-результат. Приветствие бота и сообщение «готово» не заменяют запись заказа или вход клиента.

3. Сохраните очередь и след ошибки до смены настроек. Пропущенные заказы и оплаты сверяйте отдельно.

4. Принимайте ремонт вместе с проверкой повтора события и сигналом ответственному при новом сбое.