Почему вебхуки Telegram Bot API перестают доставлять сообщения AI SaaS ботам

Вчера ваш AI SaaS бот прекрасно отвечал пользователям. Сегодня — гробовая тишина: ошибок в логах нет, падения нет, просто... ничего. Пользователи пишут и не получают ответов, а вы понятия не имеете, сколько времени это уже продолжается.

Это один из самых распространённых пожаров поддержки для команд, запускающих Telegram-ботов в масштабе. Бот не упал. Вебхук просто перестал доставлять сообщения, а Telegram никак не сигнализирует об этом, пока вы сами не начнёте разбираться.

Почему вебхуки Telegram перестают доставлять сообщения?

Bot API от Telegram отключает ваш вебхук после серии неудачных попыток доставки — обычно в течение нескольких часов, если ваш endpoint постоянно превышает таймаут, возвращает ответы не с кодом 200 или использует недействительный/просроченный SSL-сертификат. Как только Telegram решает, что ваш endpoint недоступен, он молча прекращает отправку обновлений — пока вы вручную не вызовете setWebhook заново, либо пока внутренняя очередь повторных попыток Telegram не сдастся окончательно.

В этом и заключается суть механики: Telegram не отличается настойчивостью в повторных попытках, в отличие от зрелых систем вебхуков. Он попробует повторить доставку в течение короткого периода, но если ваш сервер не ответит чистым 200 OK достаточно быстро, обновления будут потеряны — не поставлены в очередь, не повторены бесконечно. Для AI SaaS бота, обрабатывающего диалоги с клиентами, это означает молчаливую потерю сообщений именно в тот момент, когда это наименее допустимо: при высокой нагрузке на сервер или во время деплоя.

Что на самом деле вызывает сбои?

Есть пять причин, которые объясняют практически все тикеты «мой бот перестал отвечать»:

• Медленный ответ endpoint'а. Если обработчик вебхука вашего бота слишком долго возвращает 200 OK — потому что ждёт вызов LLM API перед ответом, — Telegram фиксирует таймаут и помечает доставку как неудачную.

• HTTP-ответы не с кодом 200. Возврат 500, 502 или даже редиректа 301 считается неудачной доставкой, даже если логика вашего бота на самом деле корректно обработала сообщение ниже по цепочке.

• Просроченные или самоподписанные SSL-сертификаты. Telegram требует валидный HTTPS. Сертификат, который незаметно истёк, — одна из самых частых первопричин того, что вебхуки замолкают без каких-либо явных ошибок.

• Перезапуски и редеплои сервера. Если процесс вашего бота перезапускается посреди диалога (что обычно для контейнеризированных AI-бэкендов при масштабировании подов), обновления «в полёте» могут быть потеряны, если вы не подтверждаете их быстро и не обрабатываете асинхронно.

• Изменения IP или инфраструктуры. Смена хостов, изменение балансировщиков нагрузки или задержки распространения DNS могут временно привести к тому, что запросы Telegram попадут на мёртвый endpoint — и этого временного разрыва достаточно, чтобы спровоцировать отключение.

Специфика AI SaaS делает ситуацию хуже среднего. Большинство AI-ботов вызывают LLM внутри обработчика вебхука перед ответом, а значит, время ответа естественным образом дольше и более нестабильно, чем у типичного бота, который просто записывает данные в очередь. Именно эта нестабильность и срабатывает таймаут доставки Telegram.

Как исправить вебхук, который перестал доставлять сообщения?

Вот реальная последовательность исправления, по порядку:

1. Сначала проверьте статус вебхука. Вызовите getWebhookInfo в Bot API — он возвращает last_error_date, last_error_message и pending_update_count. Это точно покажет, когда и почему всё сломалось, вместо того чтобы гадать.

2. Разделите подтверждение и обработку. Возвращайте 200 OK сразу при получении, а затем обрабатывайте вызов LLM и отправляйте ответ асинхронно отдельным вызовом sendMessage. Не заставляйте Telegram ждать, пока отработает ваш AI-инференс.

3. Убедитесь, что срок действия SSL-сертификата не подходит к концу. Настройте напоминание в календаре или автоматический мониторинг сертификатов — это самая частая причина молчаливых сбоев.

4. Перерегистрируйте вебхук после любого изменения инфраструктуры. Каждый раз при смене хоста, редеплое с новым IP или ротации сертификатов явно вызывайте setWebhook заново, а не полагайтесь на то, что настройка сохранилась.

5. Добавьте health-check по принципу «мёртвой руки». Периодически пингуйте собственный endpoint вебхука и получайте оповещение, если он перестаёт отвечать, вместо того чтобы ждать жалобы пользователя.

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

Если вы строите всё это с нуля самостоятельно, вам также придётся отвечать за логику повторов, верификацию по сигнатурам и мониторинг — всю эту обвязку, которая не имеет никакого отношения к реальной логике вашего бота.

Есть ли более надёжный способ обрабатывать доставку событий для Telegram-воркфлоу?

Если сырые вебхуки Bot API продолжают молчаливо отказывать, стоит присмотреться к платформе, которая уже построила за вас слой надёжности, вместо того чтобы изобретать его заново. API CRMChat включает инфраструктуру вебхуков с до 10 повторных попыток в течение примерно 24 часов с экспоненциальной задержкой, 30-секундным таймаутом доставки и автоматическими оповещениями в Telegram, которые приходят вам, если вебхук автоматически отключается после 3 дней без успешной доставки. Это принципиально другой уровень надёжности по сравнению с базовой попыткой доставки в Bot API.

CRMChat также подписывает каждую доставку вебхука подписью HMAC-SHA256 в заголовке X-Webhook-Signature, плюс уникальным X-Webhook-Id для отслеживания идемпотентности — так что вам не придётся каждый раз заново вручную выстраивать верификацию подписи и логику дедупликации при любом изменении бэкенда бота. События срабатывают при создании, обновлении и удалении контактов, и вы можете напрямую подключить их к n8n, Make, Zapier или собственному бэкенду, не прописывая логику повторов вручную.

Для AI SaaS команд это особенно важно, потому что логика вашего бота и так сложна — вызовы LLM, цепочки промптов, обращения к базе знаний. Вы не хотите, чтобы слой доставки сообщений был самым хрупким звеном. Если вы также используете AI-агентов, которым нужно напрямую действовать от имени Telegram-аккаунтов, а не просто принимать события, CRMChat поддерживает MCP (Model Context Protocol), позволяя AI-клиентам вроде Claude, Cursor, ChatGPT и n8n автоматизировать действия в Telegram через подключённый аккаунт вместо сырой интеграции по вебхуку.

Что стоит мониторить, чтобы заметить проблему раньше пользователей?

• Настройте автоматическую проверку поля pending_update_count из getWebhookInfo — если число постоянно растёт, значит доставки накапливаются в очереди и проваливаются.

• Оповещайте себя о любом ответе не с кодом 200 от собственного обработчика вебхука, а не только о жёстких падениях.

• Отслеживайте сроки истечения SSL-сертификатов отдельно от общего мониторинга инфраструктуры — это причина, про которую забывает большинство команд, пока она их не подводит.

• Логируйте heartbeat при каждом полученном обновлении, чтобы разрыв в 2 часа был виден на дашборде, а не обнаруживался через тикет поддержки.

• Если вы используете платформу со встроенными повторами и оповещениями об автоотключении, убедитесь, что эти оповещения в Telegram действительно приходят в канал, который кто-то отслеживает, а не в заглушённую группу.

Надёжность вебхуков — одна из тех вещей, на которые никто не закладывает время, пока это не стоит им выходных. Если вы масштабируете AI-бота в Telegram и устали нянчиться с SSL-сертификатами и логикой повторов, стоит сравнить то, что вы строите вручную, с тем, что уже встроено в такую платформу, как CRMChat — подробности настройки смотрите в Help Center, или узнайте, как аутрич и событийно-ориентированные воркфлоу связаны между собой в гайде по martech-стеку для Telegram-первой лидогенерации. Тот же паттерн молчаливых сбоев проявляется и в ботах доставки торговых сигналов, которые перестают отправлять алерты — если у вас работают оба типа ботов, исправления почти полностью совпадают.