Как понять, что сайт упал, а не просто тормозит
Сайт может быть полностью недоступен, отвечать ошибкой, открываться только у части пользователей или работать настолько медленно, что клиент считает его упавшим. Для диагностики важно смотреть не один признак, а набор сигналов: HTTP-статус, TTFB, DNS, SSL, редиректы, географию и повторяемость ошибки.
Таймлайн инцидента
Демо показывает разницу между ручной проверкой и автоматическим мониторингом.
Полное падение сайта и частичный сбой — разные ситуации
Полное падение обычно заметно сразу: сайт не открывается ни у кого, запросы заканчиваются timeout, DNS не резолвится или сервер возвращает 5xx. Но на практике часто встречаются частичные сбои. Например, главная страница открывается, а каталог, корзина, оплата или личный кабинет не работают.
Частичный сбой сложнее заметить вручную. Команда может открыть главную, увидеть 200 OK и решить, что всё в порядке. Клиент при этом не может отправить заявку или оплатить заказ. Поэтому мониторинг сайта должен проверять не только факт открытия главной, но и критичные URL, статус ответа, скорость и историю инцидентов.
- полное падение: сайт недоступен почти всем пользователям
- частичный сбой: ломается отдельный раздел или сценарий
- деградация: сайт отвечает, но слишком медленно
- региональная проблема: сбой виден только части аудитории
Какие признаки говорят, что сайт действительно упал
Первый сигнал — повторяемая ошибка снаружи вашей инфраструктуры. Если внешний checker, мобильная сеть и несколько пользователей видят одну и ту же проблему, это почти наверняка не локальный сбой. Второй сигнал — технический ответ: timeout, connection refused, DNS error, SSL warning или HTTP 5xx.
Не менее важен временной контекст. Однократный скачок TTFB на несколько секунд может быть шумом. Серия ошибок или несколько подряд неудачных проверок — уже инцидент. В мониторинге удобно задавать пороги и подтверждение по нескольким проверкам, чтобы не будить команду из-за одного сетевого всплеска.
- ошибка воспроизводится из нескольких сетей
- HTTP-статус 500, 502, 503 или timeout
- несколько проверок подряд завершаются неуспешно
- пользователи сообщают о проблеме с одним и тем же сценарием
Почему медленный сайт тоже считается проблемой доступности
Формально сайт может отвечать HTTP 200, но если первый байт приходит через 5-10 секунд, пользователь воспринимает это как падение. Особенно это критично для страниц входа, корзины, оплаты, формы заявки и административной панели. Медленная работа бьёт по конверсии почти так же, как явная ошибка.
TTFB помогает увидеть проблему до того, как она превратится в 5xx. Рост TTFB часто появляется рядом с высокой нагрузкой CPU, нехваткой RAM, медленными SQL-запросами, зависшими внешними API или заполненным диском. Поэтому доступность сайта лучше оценивать вместе со скоростью ответа и серверными метриками.
- TTFB выше 800-1200 мс уже требует внимания для многих сайтов
- медленный backend может отдавать 200, но терять пользователей
- повторяющиеся пики TTFB важнее одиночного всплеска
- скорость ответа нужно смотреть в связке с нагрузкой сервера
Как доказать факт падения без споров в чате
В командах часто возникают споры: “у меня работает”, “у клиента не работает”, “это интернет”, “это хостинг”. Без мониторинга такие разговоры превращаются в обмен скриншотами. История проверок снимает часть неопределённости: видно время, статус, длительность, восстановление и повторяемость.
Хорошая запись инцидента содержит не только факт “сайт упал”, но и контекст: какой URL проверялся, какой статус пришёл, сколько был TTFB, был ли редирект, что происходило с сервером и когда пришло восстановление. Эти данные помогают быстрее найти корневую причину.
- фиксируйте URL, статус и время проверки
- смотрите длительность, а не только факт ошибки
- сравнивайте инцидент с метриками сервера
- используйте историю для повторяющихся проблем
Когда нужно уведомлять ответственных
Уведомление должно приходить тогда, когда есть действие. Если сайт не открылся один раз из-за сетевого шума, это можно записать в историю. Если проблема повторилась, затронула важный URL или длится больше заданного порога, нужен сигнал ответственному сотруднику.
Для бизнеса важно получать не только уведомление о падении, но и уведомление о восстановлении. Иначе команда знает, что проблема началась, но не понимает, закрылась ли она сама, помогло ли вмешательство и сколько фактически длился простой.
- уведомляйте по подтверждённому инциденту, а не по одиночному шуму
- разделяйте критичные URL и второстепенные страницы
- отправляйте событие восстановления
- держите историю инцидентов для отчётов и разбора
Какие данные сохранить для разбора инцидента
Если сайт действительно упал, после восстановления важно не потерять технический контекст. Сохраните статусы проверок, TTFB, цепочку редиректов, время первого сбоя, время восстановления и список затронутых URL. Эти данные помогают понять, был ли сбой инфраструктурным, приложенческим или связанным с внешним сервисом.
Для повторяющихся проблем особенно полезно сравнивать инциденты между собой. Если сайт падает по ночам, ищите бэкапы, cron-задачи и обслуживание провайдера. Если сбои идут после релизов, смотрите деплой, миграции и прогрев кеша. Если проблема появляется в часы пик, проверяйте ресурсы сервера и базу данных.
- сохраняйте технический статус, а не только скриншот ошибки
- сравнивайте инцидент с деплоями и фоновыми задачами
- отмечайте, какие URL были затронуты
- проверяйте повторяемость по времени суток и дням недели
Что проверить дальше
Частые вопросы
HTTP 200 означает, что сайт не упал?
Не всегда. Сайт может отдавать 200, но быть слишком медленным, показывать некорректный контент или ломаться на бизнес-критичных сценариях.
Как отличить падение от временного сетевого сбоя?
Проверьте сайт из нескольких сетей и смотрите повторяемость. Несколько неуспешных проверок подряд и одинаковый симптом у разных пользователей говорят в пользу реального инцидента.
Нужно ли мониторить только главную страницу?
Нет. Главная может открываться, а каталог, форма заявки, корзина или личный кабинет могут быть недоступны. Важно проверять ключевые URL.
Почему важно уведомление о восстановлении?
Оно показывает длительность простоя и помогает понять, закрылась ли проблема. Без события восстановления команда не видит полный жизненный цикл инцидента.
Контролируйте сайт автоматически
Проверяйте доступность, TTFB, SSL, серверные метрики и получайте уведомления ответственным.