Мониторинг сайта: как узнать о падении раньше клиентов

Мониторинг сайта - это автоматические проверки, которые каждые 1-5 минут запрашивают ваши страницы со стороны и шлют оповещение, как только что-то сломалось. Минимальный рабочий набор состоит из пяти проверок: доступность главной и двух-трёх ключевых страниц по коду ответа 200, наличие на странице контрольной фразы (чтобы поймать «белый экран» при живом сервере), срок действия SSL-сертификата и домена, доставляемость заявок с форм и факт успешного создания резервной копии. Базовый уровень собирается за 30 минут и обходится бесплатно: доступность умеют проверять Яндекс Метрика и Яндекс Вебмастер, бесплатные тарифы внешних сервисов дают интервал проверки около 5 минут. Актуально на октябрь 2026 года.

Разница между «узнали сами за 2 минуты» и «узнали от клиента через 6 часов» - это не технический нюанс, а деньги и репутация. Ниже разбираем, что именно нужно мониторить (семь уровней, от пинга до заявок), как собрать базовую схему за полчаса, какие интервалы и пороги выбрать, чтобы не утонуть в ложных тревогах, куда слать оповещения ночью и что делать в первые десять минут после алерта. В конце - пять типовых ошибок настройки, разбор стоимости и ответы на частые вопросы.

Почему о падении сайта обычно узнают от клиентов

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

По опыту Honey Hunters Digital, самые дорогие простои почти всегда происходят в «слепое время»: ночью, в выходные, в праздники и в первые часы после обновления CMS или переезда на другой хостинг. Именно тогда никто из команды в сайт не смотрит, а реклама продолжает крутиться и списывать бюджет за клики по неработающей странице.

Вторая причина - проблема редко выглядит как полное падение. Чаще это частичная поломка: сайт открывается, но корзина не оформляет заказ; страницы грузятся, но форма молча не отправляет письмо; каталог работает, а обмен с 1С встал и цены замерли на позапрошлой неделе. Человек, который зашёл проверить «работает ли сайт», увидит зелёную картину и пойдёт дальше. Поймать такое может только проверка, которая знает, какой именно результат считается нормальным.

Третья причина - люди не жалуются, а уходят. Статистика по формам обратной связи и чатам на сайтах наших клиентов говорит об одном и том же: о поломке сообщает в лучшем случае один посетитель из нескольких десятков столкнувшихся. Остальные просто закрывают вкладку и идут к конкуренту. То есть к моменту, когда вам написали «у вас сайт не работает», вы уже потеряли трафик, который за этот день оплатили.

Сколько реально стоит час простоя

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

Простой пример для небольшого интернет-магазина: месячная выручка с сайта 1 500 000 ₽, активных часов продаж примерно 300 в месяц, значит час простоя - около 5 000 ₽ упущенной выручки. Если в это время крутится контекстная реклама на 60 000 ₽ в месяц, добавьте ещё примерно 200 ₽ за час впустую. Трёхчасовое ночное падение обойдётся дешевле дневного, но ночной трафик у магазинов тоже есть, и ноль заказов с 23:00 до 02:00 заметен в статистике.

Для сайта услуг арифметика другая, но не менее болезненная. Если с сайта приходит 30 заявок в месяц, а средняя сделка приносит 50 000 ₽, то одна потерянная заявка стоит столько же. День недоступности в сезон - это минус одна-две сделки, которые уже никогда не вернутся: человек оставил заявку у того, чей сайт открылся.

Отдельная статья потерь - поисковые позиции. Если робот Яндекса или Google приходит на сайт в момент, когда сервер отдаёт 5xx, страницы начинают вылетать из индекса. Разовый короткий сбой поисковик простит, систематические - нет. Мы подробно разбирали эту механику в материале о том, почему сайт пропадает из поиска: регулярные ошибки при обходе входят в список первых подозреваемых.

Что именно нужно мониторить: семь уровней

Мониторинг - это не одна галочка «сайт жив», а несколько слоёв проверок, каждый из которых ловит свой тип аварии. Пинг главной страницы не поймает сломанную форму, а проверка формы не поймает истекающий домен. Ниже - полный набор в порядке приоритета: первые три уровня нужны всем, остальные добавляются по мере роста проекта.

Важная деталь про уровень 1: проверять только главную страницу недостаточно. Главная часто отдаётся из кэша или с CDN и остаётся доступной, когда база данных уже недоступна. Добавьте в проверки хотя бы одну страницу, которая обязательно обращается к базе: карточку товара, страницу услуги, результат поиска по каталогу.

Базовый мониторинг за 30 минут: пошагово

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

1. Включите мониторинг доступности в Яндекс Метрике (раздел «Мониторинг - Доступность сайта»). Он бесплатный, проверяет главную страницу и шлёт уведомления на почту и в приложение. Это самый быстрый способ получить хоть что-то за две минуты.
2. Заведите внешний uptime-сервис и добавьте 3-5 мониторов: главная, страница услуги или карточка товара, страница контактов, адрес корзины или формы заявки. Бесплатные тарифы популярных сервисов дают интервал проверки около 5 минут, чего для начала достаточно.
3. Для каждого монитора задайте проверку по ключевому слову, а не только по коду ответа. Выберите фразу, которая точно есть на странице и которой точно не будет на заглушке хостера: название компании, текст кнопки «Оставить заявку», артикул товара.
4. Добавьте проверку SSL и домена. Большинство сервисов умеет предупреждать за 30, 14 и 7 дней до истечения сертификата. Отдельно поставьте напоминание в календарь на дату продления домена: домен важнее сертификата, его потеря выключает сайт и почту целиком. Что происходит при просрочке, мы разбирали в статье про истёкший SSL-сертификат.
5. Настройте канал оповещений, который вы точно увидите. Почта ночью не работает: письмо прочитают утром. Телеграм-бот, push в приложении или SMS - работают. Сделайте отдельный чат «Авария сайта», куда падают только алерты и ничего больше.
6. Поставьте контроль бэкапов. Самый простой способ - сервис типа «кнопки жизни»: скрипт резервного копирования после успешного завершения дёргает специальный URL, и если дёрганья не было в срок, сервис поднимает тревогу. Это ловит самую опасную ситуацию, когда копии молча перестали создаваться. Подробнее - в материале о резервных копиях сайта.
7. Проверьте, что оповещения доходят. Остановите сайт на минуту в техническое окно или временно укажите в мониторе заведомо несуществующий адрес и убедитесь, что сообщение пришло туда, куда нужно, и в нём понятно, что сломалось.

Последний пункт пропускают чаще всего, а он решающий. Ненастроенный мониторинг и мониторинг, чьи письма уходят в спам на забытый ящик, одинаково бесполезны. Проверяйте каналы оповещений хотя бы раз в квартал.

Интервалы, пороги и борьба с ложными тревогами

Правильные настройки - это компромисс между скоростью реакции и количеством шума. Рабочее правило: проверка каждые 1-5 минут, подтверждение сбоя из второй географической точки и алерт только после двух-трёх неудачных проверок подряд. Так вы узнаете о реальной аварии за 3-10 минут и не получите ночной звонок из-за одной потерянной сетевой пакетной секунды.

Что стоит настроить обязательно:

• Подтверждение из нескольких точек. Любой нормальный сервис перед тем, как объявить сайт лежащим, перепроверяет его с другого сервера. Если этого не делать, вы будете ловить сбои не сайта, а канала связи проверяющего.
• Таймаут ответа, а не только код. Сайт, который отвечает 200, но за 25 секунд, для посетителя мёртв. Ставьте порог в 10-15 секунд на полную отдачу страницы.
• Отдельный порог «медленно, но живо». Если время ответа выросло вдвое против нормы, это не авария, но повод посмотреть логи до того, как сервер ляжет окончательно.
• Техническое окно. Перед плановыми работами ставьте мониторинг на паузу, иначе команда привыкает игнорировать алерты. Привычка игнорировать - главный враг всей затеи.
• Разные уровни важности. Падение сайта - срочный канал с звуком. Сертификат истекает через 14 дней - обычное письмо. Если всё летит в один чат с одинаковым приоритетом, через месяц этот чат будет на беззвучном режиме.

Отдельно про частоту: интервал в 1 минуту имеет смысл для интернет-магазинов и сервисов, где простой сразу конвертируется в потерянные деньги. Для сайта услуг и корпоративного сайта 5 минут - вполне достаточная точность, разница между «узнали за 2 минуты» и «узнали за 7» на практике не отражается на результате.

Чем проверять: типы инструментов и вилки цен

Инструменты делятся на четыре группы, и в реальном проекте обычно сочетаются две-три из них. Цены ниже - рыночные вилки на октябрь 2026 года, они нужны для ориентира при планировании бюджета.

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

Мониторинг того, что пинг не видит

Самые дорогие поломки обычно не роняют сайт, а тихо ломают одну функцию. Сайт отвечает 200, страницы открываются, посетители ходят, а заявки не доходят. Такие вещи ловятся только сценарными проверками, когда робот не просто запрашивает страницу, а выполняет действие и сверяет результат.

Формы заявок. Самая частая и самая незаметная авария. Ломается она после обновления CMS, смены почтового пароля, переезда на другой хостинг или ужесточения политик почтового провайдера. Минимальная защита: раз в сутки автоматически отправлять тестовую заявку с пометкой и проверять, что письмо пришло и запись появилась в CRM. Если автоматизировать некому - поставьте человеку в задачи еженедельную ручную проверку, это пять минут.

Оплата. Для магазина отдельно мониторится доступность платёжного шлюза и прохождение тестового платежа. Обрыв здесь означает, что посетители доходят до последнего шага и уходят.

Обмен с учётной системой. Если на сайт выгружаются цены и остатки из 1С, нужна проверка не факта запуска обмена, а свежести данных: когда в последний раз менялась цена хотя бы у одного товара. Обмен может формально отрабатывать и при этом ничего не передавать. Мы описывали типичные грабли таких интеграций в разборе интеграции сайта с 1С.

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

Скорость. Деградация производительности почти никогда не бывает мгновенной: сначала страница грузится 2 секунды, через полгода 6, и никто не замечает перехода. Следите за показателями по реальным пользователям, а не только за разовыми замерами. Какие метрики действительно важны, мы разбирали в статье про ускорение сайта и Core Web Vitals.

Кому приходит алерт и кто на него реагирует

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

Минимальный регламент, который стоит записать на одну страницу и положить туда, где его найдут:

1. Кто первый получатель алерта в рабочее время и кто ночью и в выходные.
2. У кого есть доступы к хостингу, панели домена, админке и базе (и где лежат пароли - в менеджере паролей, а не в переписке).
3. Какие три действия выполняются до звонка подрядчику: проверить, лежит ли сайт у всех или только у вас, посмотреть статус хостинга, заглянуть в логи ошибок.
4. Телефон и канал экстренной связи с подрядчиком, и в какое время он отвечает.
5. Кто и что пишет клиентам, если простой затянулся дольше часа.

Время реакции - это то, что фиксируется в договоре на сопровождение. Чем короче обещанный срок отклика и чем шире окно дежурства, тем дороже тариф, и это нормальная экономика. На что смотреть в формулировках, мы подробно разбирали в материале про SLA в поддержке сайта.

В нашей технической поддержке мониторинг входит во все тарифы по умолчанию и работает в связке с «Красной кнопкой»: алерт приходит не только клиенту, но и дежурному инженеру, у которого уже есть доступы и история проекта. Базовый тариф начинается от 15 000 ₽ в месяц и включает 4 часа работ и «Красную кнопку» на критические инциденты; часы в нём не переносятся на следующий месяц. Тариф на 51 000 ₽ в месяц даёт час работ по 3 000 ₽ с переносом неизрасходованных часов, тариф на 96 000 ₽ в месяц - час по 2 900 ₽, тоже с переносом. Какие именно работы входят в сопровождение, мы перечисляли в чек-листе работ по техподдержке.

Первые 10 минут после алерта: чек-лист

Правильные действия в первые минуты экономят часы. Порядок простой: сначала подтвердить, что проблема реальна и общая, потом определить слой, где она живёт, и только потом что-то чинить.

1. Минута 1. Откройте сайт сами, желательно с мобильного интернета, а не из офисной сети. Так вы отсечёте проблему своего провайдера или локального DNS.
2. Минута 2. Проверьте сайт через внешний сервис «доступен ли сайт», который смотрит из нескольких городов. Если из половины точек открывается, проблема сетевая или региональная, а не на сервере.
3. Минута 3. Посмотрите код ответа. 500 и 502 указывают на приложение или веб-сервер, 503 - часто на перегрузку или блокировку хостером, таймаут без ответа - на сеть или упавший сервер целиком.
4. Минута 4. Зайдите в панель хостинга: нет ли уведомления об аварии, превышении лимитов, блокировке за нагрузку или неоплате.
5. Минуты 5-7. Откройте лог ошибок сайта и веб-сервера. В 8 случаях из 10 там прямым текстом написана причина, особенно если недавно что-то обновляли или правили.
6. Минута 8. Вспомните, что менялось за последние сутки: обновление CMS или модуля, правка кода, выкладка, смена версии PHP, импорт данных. Откат последнего изменения - самое быстрое лечение.
7. Минуты 9-10. Если причина не ясна, подключайте подрядчика и параллельно уберите ущерб: поставьте рекламные кампании на паузу, чтобы не сливать бюджет на неработающий сайт.

Развёрнутый вариант этой проверки для тех, кто разбирается сам, мы собрали в отдельной инструкции «Сайт не работает: что проверить самому».

Пять ошибок в настройке мониторинга

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

1. Проверяется только главная страница. Она чаще всего кэшируется и переживает падение базы. Ставьте в проверки страницу, которая обязательно лезет в базу данных.
2. Алерты идут на общую почту. Ящик вида info@ читают утром, и то не всегда. Критические оповещения должны идти в канал, который звенит: мессенджер, push, SMS.
3. Нет проверки по содержимому. Заглушка хостера «Аккаунт заблокирован» отдаёт код 200. Монитор доволен, сайт не работает.
4. Никто не реагирует. Алерты приходят сотруднику, который уволился полгода назад, или в чат, где их никто не читает. Проверяйте маршрут раз в квартал.
5. Мониторинг стоит на том же сервере, что и сайт. Классика: сервер падает вместе с системой, которая должна была об этом сообщить. Внешняя проверка обязана быть снаружи.

Как понять, что мониторинг работает

Проверить это можно по четырём признакам, и все они измеримы. Если хотя бы один не выполняется, схему стоит донастроить.

• За последние полгода ни об одной поломке вы не узнали от клиента или менеджера по продажам - все инциденты первыми зафиксировали проверки.
• У вас есть история простоев за период: сколько минут сайт был недоступен за месяц и по каким причинам. Без цифр нельзя предъявить претензию хостингу и нельзя понять, пора ли переезжать.
• Ложных тревог не больше одной-двух в месяц. Если больше, алерты скоро начнут игнорировать.
• Хотя бы раз проверка срабатывала по-настоящему, и вы знаете, сколько времени прошло от события до оповещения и от оповещения до починки.

Хороший ориентир по срокам для небольшого бизнес-сайта: обнаружение в пределах 5 минут, подключение исполнителя в пределах 30 минут в рабочее время, устранение типовой аварии (упавший сервис, ошибка после обновления, закончившееся место на диске) в пределах 1-3 часов. Если вы укладываетесь в эти рамки, мониторинг у вас работает.

С чего начать прямо сегодня

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

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

Если возиться с этим некогда, а сайт приносит деньги - отдайте задачу нам. Мы в Honey Hunters Digital настраиваем мониторинг на проектах клиентов как часть сопровождения сайта: собираем проверки под конкретный проект, включая формы и обмены с учётной системой, выводим алерты на дежурного инженера и раз в месяц присылаем отчёт по доступности. Напишите нам через страницу контактов, расскажите, на чём сделан сайт и что в нём критично, и мы предложим схему под вашу ситуацию. А если хочется сначала просто почитать, как такие штуки устроены у других - заглядывайте в наш телеграм-канал «Тусовка владельцев сайтов», там мы разбираем подобные истории короткими постами, без лишней теории.

Частые вопросы

Какой интервал проверки выбрать?
Для сайта услуг и корпоративного сайта хватает 5 минут, для интернет-магазина и сервисов с онлайн-оплатой стоит брать 1 минуту. Алерт настраивайте после двух-трёх неудачных проверок подряд с подтверждением из другой точки, иначе получите много ложных тревог.

Хватит ли бесплатного мониторинга?
Для старта да. Бесплатные тарифы закрывают проверку доступности нескольких адресов с интервалом около 5 минут и контроль SSL. Платить имеет смысл за более частые проверки, проверки сценариев (форма, оплата), историю простоев и нормальные интеграции с мессенджерами.

Мониторинг защищает от взлома?
Нет, он не защищает, но сильно сокращает время обнаружения. Проверка по содержимому страницы ловит подмену контента, контроль изменений файлов - появление чужого кода, а уведомления Яндекс Вебмастера сообщают о заражении, которое заметил поисковик. Защита - это другое: обновления, пароли, права доступа и резервные копии.

Нужно ли мониторить сайт, если им занимается подрядчик?
Нужно убедиться, что мониторинг настроен и что алерты идут не только подрядчику, но и вам. Это не вопрос недоверия, а вопрос прозрачности: вы должны видеть историю простоев и понимать, за какое время инциденты закрываются.

Сколько стоит поставить мониторинг под ключ?
Настройка базовой схемы (5-7 проверок, оповещения в мессенджер, контроль SSL и бэкапов) - это обычно 2-4 часа работ специалиста. У клиентов на сопровождении эти часы берутся из тарифа: базовый начинается от 15 000 ₽ в месяц и включает 4 часа работ плюс «Красную кнопку».

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