Мониторинг сайта с уведомлениями в Telegram: что проверять после запуска и как не пропустить сбой

После запуска интернет-магазина или веб-сервиса ручная проверка всех страниц быстро становится рутиной. Разработчик сервиса reChecker предлагает разбить мониторинг на три задачи: контроль доступности, отслеживание изменений важных полей и технический аудит ссылок. Все они могут отправлять уведомления в Telegram, чтобы ответственный узнавал о проблеме без ежедневного обхода сайта.

Первый сценарий — монитор доступности. Он опрашивает заданный URL каждые пять минут и фиксирует HTTP-статус, время ответа и причину сбоя. Алгоритм не поднимает тревогу после единственной неудачной попытки: падение подтверждается только повторными проверками.

Сетевой отказ или ошибка сервера от 500 переводят адрес в состояние «недоступен». Код 404 сам по себе падением не считается. Если в настройках указан обязательный текст или порог времени ответа, их нарушение при статусе 200 даёт статус ухудшения — degraded.

Поиск текста чувствителен к регистру, а замер времени не равен полной загрузке страницы в браузере. Уведомления приходят только о подтверждённом падении и восстановлении доступности; сигнал об ухудшении нужно искать в истории. Второй инструмент следит за изменениями SEO-полей, например заголовка H1.

Периодичность — 30 минут. Система сохраняет первый полученный снимок как базу. Если следующий ответ отличается, делаются ещё два запроса с паузой.

Новое состояние принимается, когда минимум два из трёх снимков совпали. Пробелы перед сравнением нормализуются, сравнивается весь набор полей, а не каждое по отдельности. Так, если H1 на странице категории сменился с «Рюкзаки для походов» на «Каталог» и это подтвердилось двумя запросами из трёх, в историю попадёт конкретное изменение.

Монитор не исполняет JavaScript и видит HTML-ответ, который может отличаться от страницы после работы скриптов. Он не определяет автора правки и не измеряет поисковые позиции — только фиксирует факт смены контента. Третья задача — ежедневный технический аудит.

В подписке «Контроль сайта» он охватывает до 100 страниц. Планировщик ставит аудит в очередь, и после обработки появляется отчёт. Аудит находит битые ссылки: например, на странице категории обнаруживается ссылка на товар, который возвращает 404.

В результате указываются адрес исходной страницы и проблемный URL, что позволяет разработчику быстро пройти по цепочке и исправить или заменить ссылку. У обхода есть лимит дополнительных запросов к ссылкам и изображениям; если он исчерпан, часть целей останется непроверенной. В отчёте сохраняются числа найденных и проверенных целей, а также признак неполного охвата.

Поэтому важно сверять список фактически обработанных URL с теми страницами, за которые команда отвечает в первую очередь. Для условного интернет-магазина стартовая схема может выглядеть так. На главную или ключевую категорию ставят монитор доступности с обязательной фразой из HTML и проверкой каждые пять минут.

Для важной категории включают отслеживание H1 с интервалом 30 минут. Ежедневный аудит запускают с расчётом, что в обработанный набор попадут критически важные страницы. На каждый вид проверок назначают ответственного и подключают канал уведомлений — в reChecker среди прочих доступен Telegram.

После сигнала о падении специалист открывает тот же URL и сверяет время и ошибку с журналами сервера. При изменении H1 сравнивает «было → стало» с задачами и публикациями в CMS. Обнаружив битую ссылку, проверяет исходную страницу и адрес назначения.

Важно понимать границы такого мониторинга. Ни один из описанных инструментов не проверяет покупательский путь целиком. После релиза, затронувшего оформление заказа, по-прежнему нужен тестовый заказ с проверкой его появления в системе.

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