Короткий ответ
Падение сайта не всегда выглядит как полный отказ сервера. Иногда домен открывается, HTTP-код остается успешным, но на странице уже видна заглушка веб-сервера, ошибка прокси, пустой шаблон или текст о временной недоступности.
Поэтому проверять нужно не только факт ответа, но и смысл страницы: нужный контент присутствует, форма или кнопка на месте, а признаки аварии отсутствуют.
Если нужно быстро понять, виден ли сбой снаружи, проверьте конкретный URL через инструмент проверки сайта. Он покажет HTTP-код, время ответа и базовую диагностику. Если URL важен для заявок, рекламы или личного кабинета, после ручной проверки добавьте его в постоянный мониторинг, чтобы видеть историю падений и восстановлений.
Что сделать в первые 5 минут
Сначала не спорьте, у кого сайт открывается, а у кого нет. Зафиксируйте проверяемый URL и пройдите короткий сценарий:
- Откройте не только главную, а именно проблемную страницу: форму заявки, корзину, оплату, личный кабинет или лендинг из рекламы.
- Проверьте URL из другой сети: мобильный интернет, другой браузер, приватное окно или внешний инструмент.
- Посмотрите HTTP-код, время ответа, редиректы и SSL. Если есть 500, 502, 503, 504, timeout или ошибка сертификата, это уже технический инцидент.
- Если код 200, проверьте содержимое: остался ли оффер, заголовок, цена, кнопка, форма, контакты или другой целевой блок.
- Сохраните время, URL и симптом. Если сбой влияет на заявки, эти данные пригодятся для поддержки или разработчика.
Такой порядок помогает быстро отделить полное падение сайта от частичной проблемы: например, когда главная открывается, а форма заявки не загружается.
Для последовательной проверки DNS, редиректов, SSL и сервера используйте чеклист диагностики падения сайта за 15 минут. В нем есть карта конкретных симптомов и переходы к узким инструкциям.
Что проверять в первую очередь
Начните с базовых сигналов: сайт отвечает, код ответа успешный, SSL-сертификат действителен, редиректы не зациклены, а время последней проверки свежее. Если проверка настроена раз в минуту, в кабинете должна быть свежая отметка времени.
После этого проверьте содержимое страницы. Для главной страницы обычно полезно требовать наличие стабильного элемента, например части заголовка или названия компании, и запрещать типовые тексты ошибок веб-сервера.
Для коммерческой страницы лучше выбрать более полезные маркеры: текст оффера, подпись кнопки, заголовок формы, название услуги или фрагмент блока с кейсом. Если эти элементы исчезли после релиза, страница может формально отвечать, но уже не выполнять свою задачу.
Если проверка показывает, что страница услуги открывается, но теряет форму, кнопку заявки или важный блок доверия, настройте для этого URL мониторинг доступности с нормальными текстовыми признаками. Если нужно быстро оценить причину и объем исправления, отправьте страницу через форму оценки задачи: укажите URL, что пропало или сломалось, когда это заметили и какие изменения были перед сбоем.
Почему одной проверки доступности мало
Пользователь оценивает не HTTP-код, а результат в браузере. Если вместо сайта открылась дефолтная страница nginx или сообщение о временной недоступности, это уже инцидент, даже если соединение технически состоялось.
Есть и обратный сценарий: сервер возвращает ошибку, но в браузере она выглядит как обычная страница сайта. Владелец видит шапку, меню и считает, что сайт живой, а пользователь не может отправить заявку или открыть нужный раздел.
Web-Puls фиксирует такие события в истории, показывает uptime за месяц и отправляет уведомления при падении и восстановлении. Для важных страниц полезно настроить не одну проверку домена, а несколько URL: главную, страницу заявки, рекламный лендинг, личный кабинет или другой критичный сценарий.
Практические сценарии
Главная открывается, а форма не работает
После обновления виджета или внешнего API форма заявки может перестать загружаться, хотя страница услуги продолжит отдавать 200 OK. Для посетителя сайт уже не работает: он не может оставить обращение.
Что проверять: URL страницы, наличие текста рядом с формой, кнопку отправки, ошибки JavaScript, логи формы и внешний ответ страницы. В мониторинг стоит добавить маркер целевого действия, например текст кнопки или заголовок формы.
Вместо сайта открылась заглушка
Иногда хостинг, прокси или CMS отдает служебную страницу с успешным кодом. Браузер открывает HTML, но пользователь видит не сайт, а сообщение о технических работах или дефолтную страницу сервера.
Что проверять: фактический текст страницы, признаки nginx, Apache, proxy error, maintenance mode, пустого шаблона или ошибки CMS. Для таких случаев помогает проверка обязательного текста и запрещенных аварийных фраз.
Сайт медленно отвечает и теряет пользователей
Если страница открывается 8-10 секунд, часть пользователей уйдет до появления ошибки. Формально сайт может быть доступен, но для рекламы, продаж и поддержки это уже проблема.
Что проверять: время ответа в разные моменты дня, повторяемость замедлений, конкретные URL и совпадение с нагрузкой, релизом, работами хостинга или внешними API.
Как реагировать на инцидент
Сначала посмотрите причину в логах падений и время последней проверки. Затем проверьте, совпадает ли проблема с релизом, изменением DNS, окончанием SSL-сертификата или ошибкой на стороне прокси.
Когда сайт восстановится, важно сохранить историю: по ней видно, сколько длился простой и насколько часто повторяется проблема.
Если проблема затрагивает заявки, оплату, личный кабинет или рекламную посадочную страницу, не ограничивайтесь фразой «сайт упал». Для быстрой диагностики полезнее короткое описание: точный URL, время, что видел пользователь, какой код ответа был снаружи и что менялось перед сбоем.
Когда подключать мониторинг
Мониторинг нужен не после первого большого сбоя, а до него. Минимальный набор для владельца сайта обычно такой:
- главная страница;
- страница заявки или контактов;
- рекламная посадочная страница;
- форма, корзина, оплата или личный кабинет, если они есть;
- SSL-сертификат и редиректы.
Для каждого URL заранее определите нормальное состояние: какой код ответа ожидается, какой текст должен быть на странице и кто получает уведомление. Тогда при инциденте команда увидит не абстрактное «что-то сломалось», а понятный сигнал по конкретной странице.
Связанные материалы помогут настроить контроль точнее: уведомление, если сайт упал, проверка текста страницы и что мониторить кроме главной страницы.