Мониторинг аптайма - это не «поставил галочку и забыл», а конкретный набор проверок, который сообщает о падении сайта раньше, чем это заметят клиенты или Яндекс. За несколько лет работы с интернет-магазинами на WooCommerce и лендингами на Tilda я видел десятки случаев, когда сайт лежал 20-40 минут посреди рабочего дня, а владелец узнавал об этом из звонка бухгалтера «а почему не приходят заказы». Дальше - какие сервисы стоит использовать, чем проверка «сайт открывается» отличается от проверки «заказ можно оформить», и как настроить всё так, чтобы алерт долетал до вас, а не терялся в спам-папке почты.
Зачем нужен мониторинг доступности сайта, если сайт вроде работает
Главная страница у большинства сайтов действительно падает редко. А вот отдельные узлы - оплата, форма заявки, вебхук CRM, скрипт расчёта доставки - валятся гораздо чаще, и обычный пользователь замечает это как «сайт не работает», хотя технически он отвечает 200 OK. Я настраивал мониторинг для интернет-магазина на WooCommerce с приёмом платежей через Т‑Банк: сервер отвечал нормально, а виджет оплаты периодически падал из-за таймаута на стороне эквайринга - без отдельного монитора на страницу checkout это заметили бы только по падению выручки в конце дня.
Цифры здесь простые: 15 минут простоя в месяц - это уже 99,97% аптайма, формально отличный показатель. Но если эти 15 минут пришлись на вечер пятницы во время рекламной кампании, потери в заказах несоизмеримы с красивым процентом в отчёте. Плюс поисковики: частые 5xx-ответы и рост времени ответа Яндекс и Google фиксируют и постепенно понижают позиции - это не разовый штраф, а накопительный эффект за пару месяцев нестабильной работы.
Как устроено отслеживание аптайма: HTTP, ping, keyword и SSL
Большинство сервисов проверяют сайт одним из нескольких способов, и стоит понимать разницу, а не ставить все монитора по умолчанию:
- HTTP(S)-проверка - запрос на URL, статус 200-299 считается «живым». Базовый вариант, ловит падения сервера и 5xx-ошибки.
- Keyword-мониторинг - проверка, что на странице присутствует конкретный текст. Ловит «белый экран смерти», когда сервер отвечает 200, но рендерится пустая страница или ошибка PHP вместо контента.
- TCP/порт-проверка - для сервисов без HTTP: почтового сервера, базы данных, кастомного API.
- Ping (ICMP) - самый грубый способ, годится для проверки, что сервер вообще в сети, но не показывает, отвечает ли веб-сервер.
- Мониторинг SSL-сертификата - отдельная проверка срока действия, чтобы не поймать «сайт недоступен» из-за забытого продления за неделю до дедлайна.
Для Tilda-сайтов со встроенными скриптами я обычно ставлю keyword-проверку на элемент, который появляется после успешной загрузки кастомного JS (например, форму с интеграцией СДЭК) - иначе падение стороннего скрипта останется незамеченным, пока сама Tilda отвечает исправно.
Сервисы для проверки работоспособности сайта: сравнение
Выбор зависит от того, нужен ли вам просто алерт в Telegram или полноценная страница статуса для клиентов.
| Сервис | Бесплатный тариф | Минимальный интервал | Особенность |
|---|---|---|---|
| UptimeRobot | 50 мониторов, 5 мин | 1 мин (платно) | Простая настройка, много интеграций для алертов |
| Better Stack (Better Uptime) | 10 мониторов, 3 мин | 30 сек | Красивая статус-страница, эскалация по звонку |
| StatusCake | 10 мониторов, 5 мин | 1 мин (платно) | Проверки из нескольких регионов на бесплатном тарифе |
| Pingdom | нет | 1 мин | Детальный RUM и анализ скорости, выше цена |
| Uptime Kuma | бесплатно (self-hosted) | настраивается вручную | Открытый код, ставится через Docker, нужен свой всегда включённый сервер |
Uptime Kuma я обычно рекомендую тем, у кого уже есть VPS под другие задачи - n8n или Telegram-бота, например, - тогда мониторинг встаёт туда же без дополнительной подписки. Если своего сервера нет, платный тариф Better Stack на пару монитора окупается уже на первом предотвращённом простое.
Настройка uptime-мониторинга: пошагово на примере UptimeRobot и Telegram
Базовая настройка занимает 10-15 минут:
- Создаёте монитор типа HTTP(s), указываете URL и интервал проверки (для интернет-магазина ставлю 5 минут на главную и 1 минуту на checkout).
- В разделе Alert Contacts добавляете Telegram - через официального бота UptimeRobot нужно написать ему /start и получить chat ID.
- Для keyword-проверки указываете текст, который должен присутствовать на странице (например, «Добавить в корзину»), и тип условия - «должен содержать» или «не должен содержать».
- Настраиваете повторную проверку из нескольких точек - это отсекает ложные срабатывания из-за проблем на стороне одного дата-центра, а не вашего сайта.
Проверить руками, как сервер отвечает и сколько времени занимает запрос, можно так:
curl -o /dev/null -s -w "%{http_code} %{time_total}sn" https://example.ru/checkoutЕсли готовых интеграций мало и нужен собственный обработчик алертов (например, отправка не в общий чат, а конкретному дежурному по расписанию), пишу небольшого aiogram-бота, который принимает вебхук от монитора и решает, куда отправить уведомление:
from aiogram import Bot
import asyncio
async def notify_down(chat_id: int, url: str):
bot = Bot(token="BOT_TOKEN")
await bot.send_message(chat_id, f"⚠️ {url} не отвечает больше 2 минут")
await bot.session.close()
asyncio.run(notify_down(-1001234567890, "https://example.ru"))Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Мониторинг интернет-магазина: checkout, эквайринг и СДЭК отдельно от главной страницы
Для e‑commerce одного монитора на главную страницу мало. Реальный путь клиента - это каталог, корзина, форма оплаты и расчёт доставки, и каждый узел может упасть независимо от остальных. На проекте с WooCommerce и приёмом оплаты через Т‑Банк я разносил это на отдельные проверки: keyword-монитор на странице оплаты (ищет кнопку «Оплатить», а не просто статус 200), отдельный HTTP-монитор на эндпоинт вебхука эквайринга с ожиданием ответа быстрее 2 секунд, и монитор на доступность API СДЭК для расчёта стоимости доставки - эта интеграция падает чаще самого сайта, потому что зависит от стороннего сервиса.
Если на сайте несколько таких критичных узлов и нужно свести их в понятную схему проверок с эскалацией по ролям (кто получает алерт по эквайрингу, кто по доставке), обычно проще заказать настройку интеграций и автоматизации под конкретный магазин, чем собирать это вручную методом проб и ошибок.
Автоматизация реакции на падение: n8n, эскалация и логирование инцидентов
Простой алерт в Telegram решает проблему, только если кто-то читает чат в 3 часа ночи. На практике я строю сценарий в n8n: вебхук от UptimeRobot или Uptime Kuma триггерит workflow, который сначала пишет в общий чат, а если через 10 минут инцидент не подтверждён вручную (нет реакции в чате), эскалирует дальше - звонок через сервис телефонии или SMS ответственному. Туда же добавляю запись инцидента с таймстампом и длительностью простоя в таблицу на своём сервере - это удобно для разбора причин падений раз в месяц и для отчёта клиенту, если есть SLA по договору.
По деньгам ориентир такой: настройка сценария в n8n с эскалацией и логированием - от 25 000 ₽, отдельный Telegram-бот под нестандартную логику уведомлений - от 30 000 ₽, а если весь мониторинг завязан на собственный скрипт на Python вместо готового сервиса - от 20 000 ₽. Для проектов, где мониторинг уже настроен, но нужно, чтобы кто-то реагировал на алерты и разбирался в причинах, беру на техподдержку от 15 000 ₽/мес.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Какой интервал проверки выбрать для мониторинга аптайма
Для большинства сайтов достаточно 5 минут - этого хватает, чтобы заметить падение до того, как о нём напишут в отзывах. Для checkout и платёжных вебхуков ставлю 1 минуту, потому что каждая минута простоя оплаты - это упущенные заказы прямо сейчас, а не абстрактная метрика.
Бесплатных сервисов достаточно или нужен платный тариф
Для одного лендинга или небольшого сайта UptimeRobot на бесплатном тарифе закрывает задачу полностью. Платный тариф или self-hosted Uptime Kuma нужен, когда мониторов больше десятка, требуется интервал короче 5 минут или важна статус-страница для клиентов.
Как отличить реальное падение сайта от разового сбоя сети
Проверки из нескольких географических точек - самый надёжный способ. Если сайт «упал» только для одного региона проверки, а из остальных отвечает нормально, это чаще проблема на стороне провайдера мониторинга или локальной сети, а не вашего сервера. Хорошие сервисы автоматически перепроверяют из другой точки перед отправкой алерта.
Нужно ли мониторить сайт, если хостинг уже обещает SLA 99,9%
SLA хостинга покрывает только доступность сервера, а не корректность работы сайта, эквайринга или сторонних интеграций вроде СДЭК. Я видел сервера с идеальным аптайм-отчётом хостинга, при этом сам сайт отдавал ошибку PHP несколько часов подряд - SLA дата-центра тут ни при чём.