Чеклист мониторинга сайта

Первый слой мониторинга — проверка доступности сайта снаружи. Нужно видеть, отвечает ли сайт, какой HTTP-статус возвращает, нет ли timeout, 5xx, неправильных редиректов или ошибок TLS. Проверяйте не только главную, но и ключевые страницы.

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

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

Для мониторинга полезно хранить историю TTFB. Один замер мало что говорит. График показывает обычный уровень, пики, деградацию после деплоя и связь с ресурсными метриками сервера.

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

Проверяйте срок SSL заранее, дату домена, корректность редиректа с HTTP на HTTPS и финальный URL. После переездов и смены домена эти проверки особенно важны: ошибки часто появляются не сразу, а после истечения кешей и TTL.

Техническая доступность не равна работоспособности бизнеса. Для интернет-магазина важны корзина, оформление заказа и оплата. Для B2B-сайта — форма заявки, обратный звонок, каталог и страница контактов. Для SaaS — авторизация, регистрация и личный кабинет.

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

Если сайт работает на собственном VPS или сервере, внешнего мониторинга недостаточно. Нужно видеть CPU, RAM, диск, load average, сеть и heartbeat агента. Эти метрики помогают понять, почему сайт стал медленным или начал отдавать 5xx.

Heartbeat показывает, что агент жив и данные свежие. Если heartbeat пропал, серверные графики могут быть устаревшими. Такой случай нужно считать отдельным событием и разбирать: агент остановлен, сервер недоступен, сеть сломана или backend мониторинга не принимает данные.

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

После инцидента важна история: время начала, длительность, статус, TTFB, SSL, серверные метрики, восстановление. Эти данные помогают не спорить о том, “был ли сбой”, а разбирать причины и предотвращать повторение.

Не обязательно автоматизировать всё за один день. Начните с внешней доступности, HTTP-статуса, TTFB и SSL для главной и ключевых страниц. Затем добавьте серверные метрики и heartbeat. После этого включите бизнес-сценарии: формы, корзину, авторизацию, оплату и важные API.

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

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

Минимальный рабочий вариант можно оформить как таблицу: URL, тип проверки, критичность, получатель уведомления, допустимое время реакции и ссылка на инструкцию. Такой формат помогает быстро вводить новые страницы, делегировать поддержку и объяснять клиенту, что именно контролируется.