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

Доступность и HTTP-статусы

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

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

• главная страница
• ключевая посадочная или каталог
• форма заявки или корзина
• страница авторизации
• важный API endpoint

TTFB и скорость первого ответа

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

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

• измеряйте TTFB регулярно
• сравнивайте с нормальным уровнем сайта
• проверяйте TTFB на разных URL
• связывайте пики с CPU, RAM, диском и логами

SSL, домен и редиректы

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

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

• SSL действителен и выпущен на нужный домен
• домен не истекает неожиданно
• HTTP корректно ведёт на HTTPS
• нет циклических или слишком длинных редиректов

Бизнес-критичные сценарии

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

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

• форма заявки отправляется
• корзина и оформление заказа работают
• авторизация доступна
• платёжный сценарий не падает
• важные интеграции отвечают

Серверные метрики и heartbeat

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

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

• CPU и load average
• RAM и возможный swap
• заполненность диска
• сетевой трафик
• heartbeat агента

Уведомления, история и разбор инцидентов

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

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

• уведомление о начале инцидента
• уведомление о восстановлении
• разные получатели для разных событий
• история статусов и метрик
• короткий postmortem после серьёзных сбоев

Как внедрить чеклист без перегруза команды

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

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

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

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

• начните с самых критичных URL
• добавляйте проверки после реальных инцидентов
• не перегружайте команду лишними уведомлениями
• пересматривайте чеклист после изменений на сайте