Как понять, что сайт упал, а не просто тормозит

Полное падение обычно заметно сразу: сайт не открывается ни у кого, запросы заканчиваются timeout, DNS не резолвится или сервер возвращает 5xx. Но на практике часто встречаются частичные сбои. Например, главная страница открывается, а каталог, корзина, оплата или личный кабинет не работают.

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

Первый сигнал — повторяемая ошибка снаружи вашей инфраструктуры. Если внешний checker, мобильная сеть и несколько пользователей видят одну и ту же проблему, это почти наверняка не локальный сбой. Второй сигнал — технический ответ: timeout, connection refused, DNS error, SSL warning или HTTP 5xx.

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

Формально сайт может отвечать HTTP 200, но если первый байт приходит через 5-10 секунд, пользователь воспринимает это как падение. Особенно это критично для страниц входа, корзины, оплаты, формы заявки и административной панели. Медленная работа бьёт по конверсии почти так же, как явная ошибка.

TTFB помогает увидеть проблему до того, как она превратится в 5xx. Рост TTFB часто появляется рядом с высокой нагрузкой CPU, нехваткой RAM, медленными SQL-запросами, зависшими внешними API или заполненным диском. Поэтому доступность сайта лучше оценивать вместе со скоростью ответа и серверными метриками.

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

Хорошая запись инцидента содержит не только факт “сайт упал”, но и контекст: какой URL проверялся, какой статус пришёл, сколько был TTFB, был ли редирект, что происходило с сервером и когда пришло восстановление. Эти данные помогают быстрее найти корневую причину.

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

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

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

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