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

Минимальный мониторинг это внешняя проверка главной страницы каждые 1-5 минут с таймаутом 15-20 секунд и уведомлением в мессенджер. Одного кода ответа 200 мало: отдельно проверяют форму заявки, срок сертификата и срок регистрации домена.

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

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

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

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

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

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

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

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

Минимум: внешняя проверка каждые 1-5 минут

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

Внешний мониторинг это отдельный сервер (или сеть серверов в разных регионах), который стучится на ваш сайт по HTTP снаружи и присылает уведомление, если ответ не пришёл вовремя или пришёл с ошибкой.

Для сайта малого бизнеса минимальный рабочий вариант выглядит так:

• проверка главной страницы каждые 1-5 минут,
• таймаут ожидания ответа 15-20 секунд,
• уведомление в Telegram или на почту при падении,
• отдельное уведомление о восстановлении, чтобы не гадать, работает сайт снова или нет.

Бесплатного тарифа UptimeRobot (до 50 мониторов с интервалом 5 минут) хватает для большинства проектов, с которыми я работаю. Если нужен интервал в минуту, придётся либо доплатить, либо собрать свой скрипт, о котором ниже. Если у вас или у клиента прописан регламент реакции на инциденты, сверьтесь заодно со статьёй про SLA для маленького сайта: мониторинг без чёткого времени реакции решает только половину задачи.

Что мониторить кроме кода ответа 200

Код 200 говорит только одно: сервер ответил и не выдал явную ошибку. Он ничего не говорит о том, что вообще-то на странице. Видел сайт, где WordPress упал в белый экран из-за фатальной ошибки PHP, но сервер честно отдавал 200 с пустым телом, потому что вывод ошибок был отключён настройками. Формально мониторинг молчал неделю, реально сайт не работал все семь дней.

Что стоит проверять дополнительно.

Ключевое слово на странице. Проверка ищет конкретную строку в ответе, например название компании в футере. Если строки нет, значит либо сайт сломан, либо это чужая заглушка хостинга, либо капча антибота. Такую проверку умеют StatusCake, Better Stack и большинство платных сервисов.

Срок действия SSL-сертификата. Let’s Encrypt выдаёт сертификат на 90 дней с автопродлением, но крон для продления иногда не срабатывает: сменился IP, слетела задача, хостер поменял конфигурацию. Уведомление за 14-21 день до истечения даёт время исправить руками, не дожидаясь предупреждения браузера у посетителей. Про сами сертификаты и типовые грабли при их выпуске я разбирал отдельно в статье про бесплатный SSL в 2026 году.

Срок регистрации домена. Реже случается, но бьёт больнее: если домен не продлили вовремя, сайт не откроется вообще ни для кого, а перехват освободившегося имени занимает от суток и не всегда удаётся. Ставьте напоминание за 30 дней до истечения, а не полагайтесь на письмо от регистратора.

Время ответа. Резкий рост TTFB с 200 миллисекунд до 3-4 секунд это ранний сигнал, что сервер перегружен или упирается в лимиты ресурсов, задолго до того, как случится настоящее падение с кодом 503.

Второй, более тяжёлый URL. Для магазина стоит проверять не только главную, но и страницу оформления заказа: главная может отдавать 200 из кэша, пока сама корзина уже не работает из-за упавшей базы или сломанной интеграции с платёжным шлюзом.

Сервисы мониторинга: что бесплатно, а что нет

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

Сервис	Бесплатный лимит	Мин. интервал бесплатно	Проверка по ключевому слову	Платный тариф от
UptimeRobot	50 мониторов	5 минут	только на платных	700 руб/мес
Better Stack	10 мониторов	3 минуты	да	1 500 руб/мес
StatusCake	10 мониторов	5 минут	да	900 руб/мес
Host-Tracker	1 монитор	10 минут	нет	400 руб/мес
Uptime Kuma	без лимита, self-hosted	20 секунд	да	бесплатно, платите за VPS

Uptime Kuma отдельная история: это открытая панель, которую вы поднимаете на своём VPS или даже на Raspberry Pi. Минимальный интервал не ограничен искусственно, уведомления идут куда угодно вплоть до Telegram и произвольных вебхуков, никто не режет число мониторов. Минус один: если ляжет именно та машина, где стоит Kuma, узнавать об этом будет некому. Поэтому у меня Kuma дублирует, а не заменяет внешний бесплатный сервис вроде UptimeRobot: два независимых наблюдателя надёжнее одного.

Свой скрипт на 20 строк как запасной канал

Когда основной сервис не устраивает по интервалу или нужен резервный канал, независимый от чужой инфраструктуры, проще всего собрать проверку из curl и cron. Вот рабочий пример, который я держу на отдельном недорогом VPS примерно за 250 рублей в месяц как раз для таких задач.

#!/bin/bash
URL="https://example.ru/"
KEYWORD="ООО Пример"
BOT_TOKEN="1234567890:AA-ваш-токен-бота"
CHAT_ID="123456789"

RESPONSE=$(curl -s -o /tmp/check_body.html -w "%{http_code}" --max-time 15 "$URL")

if [ "$RESPONSE" != "200" ] || ! grep -q "$KEYWORD" /tmp/check_body.html; then
  curl -s -X POST "https://api.telegram.org/bot$BOT_TOKEN/sendMessage" 
    -d chat_id="$CHAT_ID" 
    -d text="Сайт $URL не отвечает или изменился. Код: $RESPONSE"
fi

Кладём файл в /opt/monitor/check.sh, даём права chmod +x check.sh, добавляем в crontab строку * * * * * /opt/monitor/check.sh, и получаем проверку раз в минуту без ограничений бесплатных тарифов. Токен бота получаете у @BotFather в Telegram, id чата берёте через метод getUpdates после первого сообщения боту.

Слабое место такого решения очевидно: если упадёт именно этот VPS, уведомлений не будет. Поэтому свой скрипт это дополнение к внешнему сервису, а не замена, и держать его стоит у другого провайдера, чем основной хостинг сайта.

Ложные срабатывания и как их гасить

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

Три причины ложных тревог, с которыми сталкивался чаще всего.

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

Вторая: одна проверка вместо серии. Хороший сервис не бьёт тревогу после первого неудачного запроса, а повторяет проверку через 30-60 секунд и только после двух-трёх подряд неудач шлёт алерт. В UptimeRobot и Better Stack это настраивается в параметрах монитора, и стоит включить сразу при первой настройке.

Третья: собственное обслуживание путают с падением. Если вы сами перезапускаете сайт на 30-40 секунд ради обновления, добавьте окно обслуживания в настройках мониторинга, иначе получите алерт на пустом месте и приучите себя игнорировать уведомления именно в те минуты, когда мониторинг реально может пригодиться.

Что делать в первые 10 минут после сигнала

Когда алерт всё же пришёл настоящий, помогает короткий проверенный порядок действий, а не паника и хаотичные клики по панели хостинга.

• Проверить сайт вручную с другого канала: мобильный интернет вместо офисного Wi-Fi, curl с VPS в другом регионе. Иногда падает не сайт, а ваш локальный провайдер или DNS-кэш.
• Открыть статус-страницу хостинга, если она есть: там часто уже написано про плановые работы или инцидент у самого хостера.
• Проверить панель хостинга на превышение лимитов: место на диске, число inode, лимит CPU и процессов.
• Посмотреть error_log за последние 20 минут: часто там сразу видна причина, будь то фатальная ошибка PHP или обрыв соединения с базой.
• Вспомнить, что менялось за последний час: обновление плагина, правка кода, чужой доступ к FTP или админке.
• Если причина не находится за 10 минут, написать клиенту заранее, до того как он сам заметит: короткое сообщение «видим проблему, разбираемся, ориентир 30 минут» снимает половину напряжения разговора.

Такой порядок можно распечатать и держать перед глазами. Мелочь, но именно она экономит нервы в 23:00 субботы, когда думать связно получается хуже обычного.

Что в итоге настроить

Минимальный рабочий комплект для сайта малого бизнеса: бесплатный аккаунт UptimeRobot с проверкой каждые 5 минут, уведомления в отдельный Telegram-чат, включённый повтор на 2-3 попытки перед алертом, и раз в квартал проверка, что письма и сообщения реально доходят, а не тонут в спаме или в чужом почтовом ящике.

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

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

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

Как настроить мониторинг доступности сайта

Заведите внешнюю проверку главной с интервалом 1-5 минут и таймаутом 15-20 секунд, а уведомления шлите в мессенджер. Почту читают не сразу. Бесплатного тарифа UptimeRobot на 50 адресов малому бизнесу хватает с запасом.

Что проверять кроме кода ответа 200

Отправку формы заявки, наличие заголовка на странице, срок действия сертификата и дату продления домена. Сайт может отдавать 200 и при этом не принимать заявки.

Как часто проверять сайт

Раз в минуту для магазина, раз в пять минут для сайта услуг. Реже смысла мало: получасовой простой к моменту сигнала уже стоил заявок.

Почему приходят ложные срабатывания

Чаще из-за короткого таймаута и разовых сетевых сбоев. Лечится подтверждением с второй точки и правилом уведомлять после двух неудачных проверок подряд, а не после первой.