Мониторинг доступности сайта: 4 метрики для контроля 24/7

13 сентября 2026 · Команда SaitHub · SEO-блог SaitHub

Каждый час простоя сайта стоит бизнесу реальных денег: потерянные заявки, сгоревший рекламный бюджет и падение позиций в поиске. Ручное обновление страницы раз в день не спасает, если сервер упадёт в 3 ночи. Автоматический мониторинг доступности 24/7 позволяет обнаруживать инциденты за секунды и уведомлять команду до того, как клиенты начнут писать в поддержку.

Зачем нужен круглосуточный контроль

Простой сайта может быть незаметен для владельца, но критичен для клиента. Если сайт не отвечает, пользователь уходит к конкуренту, и вернуть его уже невозможно. В e-commerce среднее время принятия решения о покупке составляет 3-5 минут, и любой сбой в этот период означает 100% потерю сделки.

Автоматический мониторинг работает по принципу «беседы с сервером»: скрипт отправляет запрос к URL и анализирует ответ. Если сервер не отвечает в течение заданного таймаута, система фиксирует инцидент. Это позволяет разделить ответственность: вы видите, что проблема на стороне хостинга или CDN, а не в коде вашего приложения.

Стоимость внедрения такого мониторинга минимальна по сравнению с убытками от простоя. Базовые сервисы стоят от 10 до 50 долларов в месяц, тогда как час простоя интернет-магазина с оборотом 100 000 рублей в день может стоить 4000-5000 рублей.

• Uptime — процент времени, когда сайт отвечал на запросы. Норма для бизнес-сайта — 99,9% или выше.
• Downtime — суммарное время простоя за месяц. При Uptime 99,9% это составляет около 43 минут.
• SLA (Service Level Agreement) — договор с хостингом о гарантированном времени работы. Часто содержит компенсацию за простой.

Какие метрики отслеживать

Следить нужно не только за тем, что сайт «жив», но и за качеством ответа. Статус 200 OK не гарантирует, что страница отрендерилась и пользователь видит контент. Например, фронтенд может упасть, а бэкенд продолжать отдавать HTML, который браузер не сможет отобразить.

Важнейшая метрика скорости ответа — TTFB (Time To First Byte). Она измеряет время от момента отправки запроса до получения первого байта данных. Для бизнес-сайтов нормальный TTFB составляет от 100 до 300 миллисекунд. Если значение превышает 500 мс, пользователи начинают воспринимать сайт как медленный, что снижает конверсию на 7-15%.

Также необходимо отслеживать статусы HTTP. Статус 500 указывает на ошибку сервера, 502 — на проблему с прокси или шлюзом, а 404 может означать, что ссылка на главную страницу битая. Мониторинг должен проверять не только корневой URL, но и ключевые страницы: каталог, карточку товара, форму заявки.

• TTFB — время до первого байта. Определяет скорость реакции сервера.
• Latency — полное время загрузки страницы. Включает загрузку скриптов, изображений и шрифтов.
• HTTP Status — код ответа сервера. 200 — успех, 4xx — ошибки клиента, 5xx — ошибки сервера.

Как настроить алерты

Детекция инцидента бесполезна, если никто не узнает о нём. Алерты должны приходить в канал, который команда проверяет в реальном времени. Для IT-команд это часто Slack или Telegram, для руководителей — SMS или push-уведомления.

Критически важно настроить пороговые значения. Алерт не должен срабатывать на единичный сбой, если он длится 2 секунды. Лучше настроить правило: уведомление отправляется, если сайт недоступен 3 раза подряд в течение 5 минут. Это отсекает ложные срабатывания из-за сетевых抖动 (скачков).

Время реакции на алерт должно быть меньше 5 минут. Если команда не реагирует на уведомление в течение 10 минут, это сигнал, что процесс инцидент-менеджмента не настроен. В это время теряются деньги и репутация.

• Slack-интеграция — алерты в рабочий чат. Позволяет сразу назначить ответственного.
• SMS-уведомления — для критических инцидентов, когда нужно будить дежурного инженера.
• Email-отчёты — сводка по доступности за день или неделю для отчётности.

Выбор инструментов мониторинга

На рынке десятки сервисов: от простых пингов до сложных систем с географическими узлами. Для малого бизнеса достаточно сервиса с проверкой из 3-5 точек мира. Для глобальных продуктов нужны узлы в каждой стране, где есть пользователи.

Цена вопроса начинается от 0 рублей за open-source решения вроде Uptime Kuma или UptimeRobot с бесплатным тарифом. Платные сервисы вроде Pingdom, New Relic или Datadog предлагают более глубокий анализ, но стоят от 50 до 500 долларов в месяц. Для старта лучше выбрать сервис с бесплатным пробным периодом и простым интерфейсом.

Важно проверить, поддерживает ли выбранный сервис проверку SSL-сертификатов. Если сертификат истечёт, браузер покажет предупреждение, и часть пользователей не смогут открыть сайт. Мониторинг должен отслеживать срок действия сертификата и предупреждать за 7-14 дней до истечения.

Географическое распределение точек проверки

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

Настройте мониторинг из 3-5 географических точек. Например, Москва, Санкт-Петербург, Екатеринбург, Минск и Алматы. Это позволит понять, где именно возникает проблема: на стороне вашего сервера или в сети провайдера. Если сайт не открывается только из одного региона, вероятно, проблема в локальной инфраструктуре.

Для сайтов с CDN (Content Delivery Network) мониторинг должен учитывать, что контент отдаётся с ближайшего к пользователю узла. Проверка должна имитировать реальный путь пользователя: DNS-запрос, соединение с CDN-узлом, получение данных.

• Multi-region monitoring — проверка из разных стран. Показывает реальную доступность для глобальной аудитории.
• CDN monitoring — контроль работы кэширующих узлов. Позволяет выявить проблемы с кэшем.
• DNS monitoring — проверка записи в DNS. Отдельная метрика, так как DNS-сбой делает сайт недоступным даже если сервер работает.

Автоматизация восстановления

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

Для простых сайтов автоматизация ограничивается перезапуском сервиса. Настройте cron-задачу или systemd-юнит, который проверяет процесс и перезапускает его при падении. Это сокращает время восстановления с часов до секунд.

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

• Auto-restart — автоматический перезапуск сервиса при падении. Сокращает время восстановления.
• Failover — переключение на резервный сервер. Работает при потере основного узла.
• Incident log — журнал инцидентов. База данных для анализа причин сбоев.