Иногда сайт не падает полностью. У владельца он открывается, главная страница отвечает, а клиенты уже пишут, что не могут зайти в личный кабинет, оформить заказ или открыть страницу из рекламы. Такой сбой легко пропустить, потому что он затрагивает не всех пользователей и не всегда виден из офиса администратора.
Поводом для темы стали июньские сообщения о кратких массовых проблемах у крупных сервисов: Tom's Guide и TechRadar писали о жалобах пользователей 22 июня 2026 года, а на Cloudflare Status в тот же день появлялись записи о повышенных ошибках и задержках в части сервисов. Для владельца сайта важен не сам инфоповод, а практический вывод: частичную недоступность нужно проверять снаружи, из разных сетей и по важным сценариям, а не только по главной странице.
Что такое частичная недоступность сайта
Частичная недоступность — это ситуация, когда сайт работает только для части пользователей или ломается не целиком. Например, главная страница открывается, но каталог отдает ошибку. Или сайт доступен через домашний интернет владельца, но не открывается у клиентов из другого региона. Еще один частый вариант: страницы загружаются, а форма заказа, корзина, авторизация или API не отвечают.
Для бизнеса такой сбой почти так же неприятен, как полное падение. Пользователь не разбирается, работает ли у вас главная страница. Если он не может выполнить нужное действие, сайт для него уже недоступен.
Почему владелец может не видеть проблему
Есть несколько причин, почему частичный сбой остается незаметным для команды сайта.
Проверка идет из одной сети
Если вы открываете сайт только из офиса или с одного домашнего подключения, вы видите маршрут именно от этой сети до сервера. У клиентов маршрут может идти через другого оператора, другой CDN-узел, другой DNS-резолвер или перегруженный сетевой участок. Поэтому у вас все выглядит нормально, а часть аудитории получает таймауты.
Проверяется только главная страница
Главная может быть закеширована и отвечать быстро, пока динамические разделы уже сломаны. Для интернет-магазина важны карточки товаров, корзина, оформление заказа и страница оплаты. Для сервиса — вход, личный кабинет, тарифы, платежи и API. Для корпоративного сайта — формы заявок и посадочные страницы из рекламы.
Ошибка зависит от сценария
Иногда сбой появляется только после конкретного действия: добавления товара в корзину, отправки формы, перехода по редиректу, загрузки файла или обращения к внешнему API. Простая проверка «открывается ли главная» такую проблему не поймает.
Статус-страница провайдера обновляется с задержкой
Статус-страницы полезны, но они не заменяют собственный мониторинг. У провайдера может быть частичная деградация, которая затрагивает не всех клиентов. Бывает и наоборот: проблема находится в вашем приложении, DNS, SSL или настройках CDN, а у провайдера в целом все штатно.
Какие признаки у частичного сбоя
Частичная недоступность редко выглядит одинаково для всех. Стоит насторожиться, если появляются такие сигналы:
- клиенты жалуются на сайт, а у сотрудников он открывается;
- жалобы приходят из одного региона, от одного оператора или с мобильного интернета;
- часть страниц возвращает ошибки 500, 502, 503, 504 или 429;
- браузер долго ждет ответ, а затем показывает таймаут;
- форма отправляется не всегда или зависает после нажатия кнопки;
- сайт открывается по HTTP, но ломается по HTTPS;
- редиректы ведут по кругу или отправляют пользователя не туда;
- изображения и скрипты грузятся, а основной HTML не отвечает;
- админка работает, а публичная часть сайта недоступна.
Один такой признак еще не доказывает аварию, но это повод проверить сайт не из одной точки, а как внешний пользователь.
Как проверить сайт вручную
Начать можно с простых действий. Они не заменят мониторинг, но помогут быстро понять масштаб проблемы.
Откройте сайт из другой сети
Проверьте сайт через мобильный интернет, другой браузер и приватное окно. Если есть коллеги или подрядчики в других городах, попросите открыть конкретные проблемные страницы. Важно просить не просто «зайди на сайт», а дать точный URL и действие: открыть каталог, отправить тестовую форму, перейти в корзину.
Проверьте не только главную
Составьте короткий список критичных адресов. Для магазина это может быть главная, категория, карточка товара, корзина и оформление заказа. Для B2B-сайта — главная, страница услуги, форма заявки и контакты. Для SaaS — главная, логин, личный кабинет и публичный API-адрес, если он есть.
Смотрите код ответа и время ожидания
Визуально страница может казаться рабочей, но сервер уже отдает неверный код ответа. Например, страница ошибки может быть оформлена в стиле сайта и возвращать 200, хотя пользователь не получил нужный контент. Поэтому полезно проверять не только факт открытия, но и HTTP-статус, время ответа и наличие ожидаемого текста на странице.
Для быстрой внешней проверки можно использовать инструмент Web-Puls «Проверить сайт». Он помогает посмотреть, отвечает ли URL снаружи, а не только с вашего компьютера.
Зафиксируйте время и симптомы
Если проблема повторяется, запишите точное время, URL, сеть, браузер, текст ошибки и действие пользователя. Эти данные помогут отличить сбой приложения от проблем DNS, CDN, хостинга или внешнего платежного сервиса.
Как настроить мониторинг, чтобы не ждать жалоб
Ручная проверка полезна в моменте, но она не работает круглосуточно. Частичный сбой может начаться ночью, в выходной или во время рекламной кампании. Поэтому владельцу сайта нужен внешний мониторинг важных точек.
Проверяйте несколько URL
Не ограничивайтесь главной страницей. Добавьте в мониторинг страницы и сценарии, где бизнес теряет заявки или продажи: лендинг из рекламы, каталог, страницу входа, форму заявки, корзину, страницу оплаты, API health-check. Если технический адрес требует авторизации, лучше подготовить безопасную публичную проверочную страницу или endpoint, который не раскрывает лишние данные.
Следите за кодом ответа
Для обычной страницы ожидаемым чаще всего будет успешный HTTP-ответ. Для редиректа важно понимать, куда он ведет. Для закрытого раздела может быть нормальным один код, а для публичной страницы — другой. Главное заранее определить, какой ответ считается рабочим именно для этого URL.
Проверяйте содержимое страницы
Если сайт вместо каталога показывает заглушку, ошибку CMS или пустой шаблон, один только статус может не помочь. Контентная проверка ищет ожидаемый фрагмент текста на странице и помогает заметить ситуации, когда сервер формально отвечает, но пользователь видит не тот результат.
Учитывайте время ответа
Сайт может не упасть, но стать настолько медленным, что пользователи уйдут. Для владельца важно видеть не только «работает/не работает», но и ухудшение скорости ответа. Резкий рост времени ответа часто бывает ранним признаком перегрузки, проблемы с базой данных, внешним API или хостингом.
Настройте понятные уведомления
Уведомления должны приходить тем, кто реально может отреагировать: владельцу проекта, администратору, разработчику или подрядчику. Если уведомления получает только общий почтовый ящик, инцидент легко потеряется. Хорошая практика — заранее договориться, кто проверяет проблему и кто принимает решение о временных мерах.
Что делать, если частичный сбой уже начался
Не стоит сразу менять все настройки подряд. Лучше действовать по порядку.
Сначала подтвердите проблему снаружи: проверьте несколько URL, разные сети и конкретные пользовательские действия. Затем посмотрите последние изменения: деплой, обновление CMS, настройки CDN, DNS-записи, SSL-сертификат, правила редиректов, изменения на хостинге. После этого проверьте логи приложения и сервера за время жалоб.
Если сайт связан с оплатой, доставкой, CRM, почтовым сервисом или внешним API, отдельно проверьте эти интеграции. Часто пользователь видит «сайт не работает», хотя фактически зависает один внешний сервис в цепочке.
Если идет платный трафик на проблемную страницу, имеет смысл временно остановить кампанию или перевести ее на рабочую страницу. Это не чинит сбой, но помогает не тратить бюджет на пользователей, которые все равно не смогут оставить заявку.
Как Web-Puls помогает заметить проблему быстрее
Web-Puls помогает регулярно проверять доступность сайта и быстрее узнавать, если важный URL перестал отвечать. Для частичных сбоев особенно полезно добавлять в мониторинг не одну главную страницу, а несколько критичных адресов: страницу заявки, каталог, корзину, личный кабинет или публичный endpoint.
Если проблему нужно не только заметить, но и разобрать технически, можно отправить заявку на профессиональную поддержку через форму Web-Puls или воспользоваться контактной информацией. Это уместно, когда сбой связан с DNS, SSL, хостингом, серверными ошибками, почтой или сложной интеграцией.
Вывод
Частичная недоступность опасна тем, что ее легко не заметить изнутри. У владельца сайт открывается, а часть клиентов уже не может оформить заказ, войти в кабинет или отправить заявку. Поэтому проверяйте сайт как внешний пользователь: из разных сетей, по нескольким URL, с контролем статуса, времени ответа и содержимого страницы.
Лучший подход — заранее определить критичные страницы и поставить их на автоматический мониторинг. Тогда первым сигналом о проблеме будет не случайная жалоба клиента, а понятное уведомление, по которому можно быстро начать диагностику.