Бесплатный мониторинг сайта: что реально можно получить без денег

Бесплатный мониторинг сайта — нормальный старт, если нужно быстро понять, падает ли сайт, API или админка. Для небольшого проекта часто достаточно внешней проверки HTTP/HTTPS, уведомления о недоступности и истории последних сбоев — покупать полноценную observability-платформу сразу не обязательно.

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

Разберём, что реально можно получить без денег, где бесплатного мониторинга достаточно, а где он создаёт ложное чувство безопасности. Заодно посмотрим на самостоятельные варианты через cron, curl и простые скрипты, а также на Free-тарифы сервисов мониторинга, включая Statuser.

Что такое бесплатный мониторинг сайта

Под мониторингом сайта обычно понимают регулярную внешнюю проверку: сервис или скрипт обращается к URL и фиксирует результат. Самая простая проверка отвечает на вопрос: открывается ли страница и возвращает ли она ожидаемый HTTP-статус.

В базовом варианте проверяются:

• доступность домена;
• ответ веб-сервера;
• HTTP-код: 200, 301, 302, 500, 502, 503 и другие;
• время ответа;
• истечение таймаута;
• иногда — наличие текста на странице;
• иногда — срок действия SSL-сертификата.

Это не то же самое, что мониторинг инфраструктуры: проверка снаружи не покажет загрузку CPU, заполнение диска, число соединений к базе или состояние очереди задач. Она показывает главное с точки зрения пользователя — сайт открылся или нет.

Если нужна база по принципам, полезно сначала прочитать материал что такое uptime monitoring и как он работает — там разобрана логика внешних проверок, интервалов, инцидентов и восстановления.

Бесплатный мониторинг обычно бывает трёх видов.

1) Free-тариф SaaS-сервиса — вы регистрируетесь, добавляете URL, выбираете интервал проверки и получаете уведомления. Не нужно поднимать сервер, писать код и обслуживать скрипты.

2) Самодельная проверка на своём сервере — например, cron запускает curl, а при ошибке скрипт отправляет сообщение в Telegram. Бесплатно по деньгам, но не бесплатно по времени и надёжности.

3) Разовые онлайн-проверки — вы вручную проверяете сайт через сторонний инструмент. Полезно для диагностики, но не мониторинг: если сайт упадёт ночью, никто вас не разбудит.

Для коммерческого сайта минимальный рабочий вариант — автоматическая проверка по расписанию и уведомление о проблеме. Остальное зависит от критичности проекта.

Что обычно дают Free-тарифы сервисов мониторинга

У большинства сервисов бесплатный тариф закрывает базовый сценарий: следить за одним или несколькими сайтами и получать алерт при падении. Для лендинга, блога, небольшого интернет-магазина или личного API этого часто достаточно.

1) Проверка HTTP/HTTPS — сервис периодически открывает URL и считает сайт доступным при корректном ответе. Иногда можно задать допустимые статусы, например 200 и 301 — норма, 500 — ошибка.

2) Уведомления о сбое — чаще всего email, Telegram или webhook. Уведомление должно приходить не только при падении, но и при восстановлении, иначе непонятно, продолжается инцидент или уже закончился.

3) Базовая история событий — список падений и восстановлений за ограниченный период. Этого хватает, чтобы понять, были ли сбои вчера, ночью или после релиза.

4) Проверка времени ответа — даже формально доступный сайт может отвечать слишком долго. Некоторые Free-тарифы показывают рост latency, но детальная аналитика обычно остаётся в платных планах.

5) Интервал проверки — например, раз в несколько минут. Чем меньше интервал, тем быстрее вы узнаёте о проблеме, но тем дороже проверка для сервиса — самые частые проверки почти всегда платные.

6) Ограниченное число мониторов — бесплатный план обычно рассчитан на несколько URL: главная страница, API healthcheck, админка, статусная страница. Для десятков доменов и endpoint'ов придётся платить.

Statuser тоже относится к этому классу инструментов: сервис проверяет сайт с заданным интервалом и присылает уведомление о сбое. Free-тариф подходит для базового мониторинга доступности без лишней инфраструктуры. Ограничения по количеству проверок, интервалам и функциям лучше смотреть в актуальных условиях тарифа — изменения бесплатного плана отдельно описываются в блоге, например в материале про обновление Free-тарифа Statuser.

Что бесплатные тарифы обычно ограничивают

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

1) Интервал проверки — бесплатный тариф может проверять сайт реже, чем нужно. При интервале 5–10 минут короткий сбой может остаться незамеченным, а об инциденте вы узнаете с опозданием. Как выбрать подходящий интервал — в статье как выбрать интервал проверки сайта.

2) Число мониторов — одного URL часто мало: главная может открываться, а /api/checkout отдавать 500, или публичная часть работать, а кабинет — лежать из-за ошибки авторизации. Бесплатный план редко покрывает все критичные маршруты.

3) Каналы уведомлений — email бесплатен почти везде, а SMS, звонки, расширенные webhooks и интеграции с incident management обычно платные. Для одиночного владельца сайта email и Telegram достаточно, для команды с дежурствами — нет.

4) География проверок — проверка из одной точки не всегда показывает реальную картину: сайт может быть доступен в одной стране и недоступен в другой из-за DNS, CDN, маршрутизации или блокировок. Мультигеография почти всегда стоит дороже.

5) Хранение истории — бесплатный тариф может хранить события недолго. Понять, что сайт падал ночью, этого достаточно; для анализа SLA и отчётов клиентам — уже нет.

6) Расширенные проверки — сценарии вроде логина, проверки корзины, многошагового synthetic monitoring, контроля JSON-поля в API-ответе или SSL по нескольким доменам часто доступны только в платных планах.

7) Командные функции — роли, несколько пользователей, расписания дежурств, эскалации и postmortem редко бывают бесплатными.

Бесплатный мониторинг хорошо отвечает на вопрос «сайт жив?», но плохо — на вопросы «почему он упал?», «кого будить?» и «какой SLA нарушен?».

Самодельный мониторинг через curl, cron и Telegram

Если хочется обойтись совсем без SaaS, можно собрать проверку самостоятельно: например, сервер раз в минуту запускает curl, проверяет HTTP-код и отправляет уведомление в Telegram при ошибке.

Минимальная логика:

• выполнить curl к нужному URL;
• получить HTTP-код и время ответа;
• если код не 200, записать ошибку;
• если ошибка повторилась несколько раз подряд, отправить алерт;
• когда сайт восстановился, отправить сообщение о восстановлении.

Пример простого скрипта:

#!/usr/bin/env bash
 
URL="https://example.com"
CODE=$(curl -L -s -o /dev/null -w "%{http_code}" --max-time 10 "$URL")
 
if [ "$CODE" != "200" ]; then
  echo "$(date -Is) $URL returned $CODE" >> /var/log/site-check.log
fi

Запуск через cron:

* * * * * /usr/local/bin/site-check.sh

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

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

Для внешнего коммерческого сайта есть фундаментальная проблема: мониторинг не должен жить на той же инфраструктуре, что и сайт. Если упадёт VPS, где работают и сайт, и проверяющий скрипт, уведомления не будет вообще. Можно вынести скрипт на отдельный сервер, добавить Telegram-бота, настроить retries и хранение истории — но это уже отдельный мини-продукт. Иногда дешевле использовать готовый Free-тариф, а время потратить на исправление реальных проблем сайта.

Если всё же хотите отправлять алерты самостоятельно, пригодится инструкция как настроить уведомления о проблемах с сервером в Telegram. Для ручной диагностики HTTP-запросов полезен материал что такое curl и как им пользоваться.

Что именно стоит мониторить бесплатно

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

1) Главная страница — базовый сигнал, что домен, DNS, TLS, CDN и веб-сервер в целом работают. Это не полная проверка, но её стоит оставить.

2) Healthcheck API — endpoint вроде /health, /status или /ready. Он должен проверять не только то, что процесс жив, но и зависимости: базу данных, кэш, очередь, доступ к внешнему API, если без него сервис бесполезен. При этом не стоит делать healthcheck слишком тяжёлым — если он ходит по всем системам и выполняет сложные SQL-запросы, мониторинг сам создаст нагрузку. Хороший healthcheck быстрый, предсказуемый и честно отражает готовность сервиса.

3) Критичный пользовательский маршрут — например, /login, /checkout, /api/orders, /cabinet. Если тариф позволяет добавить только несколько URL, выбирайте те, где простой напрямую влияет на пользователей или деньги.

4) SSL-сертификат — истёкший сертификат может сделать сайт недоступным для большинства пользователей, даже если сервер жив. Бесплатный мониторинг SSL есть не везде, но если доступен — его стоит включить. Подробнее — в статье почему важен мониторинг SSL-сертификатов.

5) Страницы за CDN или reverse proxy — если сайт использует Cloudflare, Nginx, балансировщик или API Gateway, проверяйте публичный URL, а не только внутренний backend. Пользователю важна работа всей цепочки.

Хороший минимум для небольшого проекта: главная страница, /health, /login, ключевой API-endpoint и SSL-сертификат основного домена. Если план позволяет меньше проверок, начните с главной и healthcheck, остальное добавляйте по мере роста проекта.

Бесплатно не значит надёжно: ложные срабатывания и слепые зоны

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

1) Сетевой сбой между мониторингом и сайтом — пакет потерялся, маршрут временно деградировал, DNS ответил медленно. Одна неудачная проверка не всегда означает реальный инцидент.

2) Слишком короткий таймаут — сайт ответил бы за 7 секунд, а мониторинг ждёт только 5. Формально это timeout, но алерт должен быть настроен осознанно.

3) Блокировка проверяющего IP — WAF, firewall или rate limiting могут принять мониторинг за бота: пользователи сайт открывают, а мониторинг видит 403, 429 или timeout.

4) Неверный ожидаемый статус — сайт редиректит с http:// на https://, а мониторинг считает 301 ошибкой. Или endpoint корректно возвращает 204, но настроен только 200.

5) Кеширование — CDN может отдавать статичную страницу, когда backend уже не работает: проверка главной зелёная, а личный кабинет недоступен.

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

Отдельная тема — false positive. Если мониторинг часто будит команду зря, его начинают игнорировать, а это опаснее, чем отсутствие мониторинга: настоящий инцидент легко пропустить среди шума. Подробнее — в статье что такое false positive в мониторинге.

Алерты тоже нужно проектировать: для небольшого сайта достаточно уведомления владельцу, для команды — правила, кто получает сообщение, когда подключается второй человек и какие события не требуют срочной реакции. Практические принципы — в материале как настроить алерты без alert fatigue.

Когда бесплатного мониторинга достаточно

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

1) Проект небольшой — личный сайт, блог, портфолио, документация, MVP, внутренний инструмент без жёсткого SLA.

2) Потери от простоя невелики — если сайт недоступен 10 минут, это неприятно, но не приводит к серьёзным финансовым последствиям.

3) Нет круглосуточной команды — если реагировать ночью за 30 секунд всё равно некому, сверхчастые проверки и сложные эскалации не дадут большой пользы.

4) Нужно покрыть базовый риск — узнать о полном падении сайта раньше, чем напишет клиент или коллега.

5) Вы только выстраиваете процесс — сначала полезно собрать историю: как часто сайт падает, сколько длится простой, какие причины повторяются.

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

Но даже бесплатный мониторинг нужно настроить аккуратно. Проверьте правильный URL, корректные ожидаемые HTTP-коды, разумный таймаут, рабочий канал уведомлений, сообщение о восстановлении, исключение плановых работ (если доступно) и реакцию на тестовое падение.

Хорошая практика — специально создать контролируемый сбой: временно закрыть тестовый endpoint, поменять ожидаемый статус или остановить staging-сервис. Так вы увидите, приходит ли алерт и понятен ли текст уведомления.

Когда пора переходить на платный мониторинг

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

Стоит переходить на платный тариф, когда:

• нужен меньший интервал проверки — разница между 1 и 10 минутами для критичного сервиса заметна;
• нужно больше мониторов — сайт состоит не из одной страницы, а из API, авторизации, корзины, платежей и админки;
• нужны проверки из разных регионов — особенно если пользователи распределены географически или сайт зависит от CDN и внешних провайдеров;
• нужны командные уведомления — один email перестаёт работать, когда есть дежурства, роли и эскалации;
• нужна история и отчётность для SLA, клиентов и постмортемов — короткой истории Free-тарифа для этого мало;
• нужны расширенные сценарии — проверка содержимого страницы, API-ответов, SSL по нескольким доменам, редиректов, авторизации;
• нужна поддержка процесса инцидентов — комментарии, назначение ответственного, плановые работы, публичные статусы.

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

Как выбрать бесплатный мониторинг сайта

Чтобы бесплатный мониторинг не превратился в формальность, оцените сервис по практическим критериям — не по количеству красивых графиков, а по тому, поможет ли он быстрее обнаружить и разобрать сбой.

• какие проверки доступны: только HTTP или ещё SSL, keyword check, TCP, ping, API — для сайта минимум HTTPS и HTTP-статус, для API важна проверка конкретного endpoint'а;
• какой минимальный интервал — сравните его с реальной потребностью: если достаточно узнавать о сбое через несколько минут, хватит Free-тарифа, если почти сразу — смотрите платные планы;
• какие уведомления есть бесплатно — email, Telegram, webhook; важны не только каналы, но и скорость доставки, понятность текста и уведомление о восстановлении;
• есть ли защита от шума — retries, подтверждение сбоя несколькими попытками, настройка таймаутов;
• сколько хранится история — для простого контроля хватит короткой, для анализа повторяющихся инцидентов нужно больше;
• можно ли понять причину сбоя — хороший алерт содержит URL, время, код ошибки, длительность ответа и текст ошибки, а не просто «сайт не работает»;
• как сервис ведёт себя при плановых работах — нужна пауза мониторинга или отметка техработ, иначе история будет загрязнена ожидаемыми сбоями;
• насколько легко перейти на платный тариф — удобно, когда Free-план — нормальный старт, а не урезанная демо-версия, и при росте проекта не придётся заново переносить проверки, контакты и историю.

Для первого запуска достаточно простого плана: добавить главный URL и healthcheck, настроить Telegram или email, выбрать интервал, проверить тестовый алерт, а через неделю посмотреть историю и уровень шума — и уже после этого добавлять критичные endpoint'ы или переходить на платный тариф, если лимитов не хватает.

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

FAQ

Можно ли настроить мониторинг сайта бесплатно без сервиса?
Да. Минимальный вариант — curl + cron + уведомление в Telegram или email. Но такое решение нужно поддерживать, защищать от ложных срабатываний и размещать отдельно от основного сайта.

Хватит ли бесплатного мониторинга для интернет-магазина?
Для старта — да, если магазин небольшой. Но лучше мониторить не только главную, а ещё корзину, оформление заказа, оплату и SSL. Когда простой начинает стоить денег, стоит перейти на платный тариф.

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

Что важнее: мониторинг сайта или мониторинг сервера?
Это разные уровни. Мониторинг сайта показывает, видит ли пользователь рабочий сервис. Мониторинг сервера помогает понять причину: CPU, память, диск, база, сеть. Лучше использовать оба подхода.