Сайт упал в пятницу вечером, а узнали об этом в понедельник от клиента, который не смог оформить заказ. Так бывает чаще, чем кажется: свой сайт никто не открывает каждые пять минут. Мониторинг доступности сайта закрывает эту дыру и стоит меньше, чем один пропущенный заказ.
Обычная реакция на предложение настроить мониторинг: "у нас надёжный хостинг, за два года ни разу не падало". Проверить это утверждение нечем: без мониторинга вы не знаете, сколько раз сайт лежал по двадцать минут ночью.
Почему о падении узнают от клиента
Владелец заходит на свой сайт редко, а когда заходит, браузер часто отдаёт страницу из кэша. Сотрудники смотрят админку, а не витрину. Клиент, который упёрся в ошибку, не звонит сообщить о проблеме, он открывает следующую строчку выдачи.
По нашим проектам на поддержке картина такая: без мониторинга типичное время от начала аварии до обращения клиента составляет 3-8 часов, а ночные и выходные падения обнаруживаются только утром в понедельник. С мониторингом уведомление приходит через 1-5 минут.
Хостинг о падении не сообщает и не обязан. Договор гарантирует доступность в процентах: 99,9% в месяц означает 43 минуты законного простоя, 99,5% уже 3,5 часа. И главное: SLA покрывает работу сервера, а не вашего сайта. Если движок упал после неудачного обновления плагина, сервер жив, а сайт нет.
Что мониторить, кроме факта "сайт открылся"
Проверка "сервер отвечает" ловит только половину аварий. Полезный набор выглядит так.
Код ответа. Смотреть именно код HTTP, а не факт соединения. 500 и 502 означают сломанный движок, 503 обычно выдаёт перегруженный сервер. Ловушка: сайт может отдавать честный код 200 и показывать белый экран.
Ключевой текст на странице. Проверка на подстроку: телефон в шапке, кнопка "Оставить заявку", название компании. Ловит белый экран, обрезанный вывод и подмену страницы после взлома, которые по коду ответа выглядят нормально.
Время ответа. Важен тренд, а не разовое значение. Рост с 0,4 до 3 секунд обычно предшествует полному падению и означает либо утечку в коде, либо подросшую нагрузку. Резкий скачок в несколько раз за час бывает первым признаком атаки, про которую мы писали в статье про защиту от DDoS.
Срок сертификата. Уведомление за 14 дней до истечения. Автопродление Let's Encrypt ломается тихо, и узнают об этом в день, когда браузер начал пугать посетителей. Какой сертификат нужен и где его брать, разбирали отдельно.
Срок домена. Самая дорогая по последствиям авария: сайт исчезает целиком, а восстановление после просрочки занимает дни.
Свободное место на диске. При заполненном диске база перестаёт писать, а сайт открывается как обычно: заказы просто не сохраняются.
Бэкапы. Мониторить не факт запуска задачи, а появление файла правдоподобного размера. Пустой архив в 4 килобайта создаётся каждую ночь как ни в чём не бывало, про эту ловушку есть отдельный разбор в статье про бэкап сайта.
Не только главная страница. Добавьте в проверки каталог, карточку товара и корзину: каталог с фильтрами ломается чаще главной.
Чем мониторить: четыре варианта
| Вариант | Интервал | Цена | Кому подходит |
|---|---|---|---|
| Бесплатный внешний сервис (UptimeRobot, Ping-Admin) | 3-5 минут | бесплатно | лендинг, визитка, блог |
| Платный тариф того же сервиса | 30-60 секунд | 500-2 000 руб/мес | магазин, онлайн-запись, сайт под рекламу |
| Свой Uptime Kuma на дешёвом VPS | от 20 секунд | 250-500 руб/мес за сервер | у кого 5 и больше сайтов |
| Zabbix или система хостера | любой | работа администратора | компании со своим сервером и админом |
Про соблазн написать свой скрипт по расписанию на том же сервере, где живёт сайт: главную аварию он не увидит, потому что ляжет вместе с сервером. Проверять надо снаружи, а свой скрипт держать для внутренних метрик: место на диске, размер бэкапа, очередь писем. У встроенного мониторинга панели хостинга тот же изъян плюс конфликт интересов: провайдер измеряет сам себя.
Интервал проверки и ложные тревоги
Пятиминутный интервал означает, что до пяти минут простоя пройдут незамеченными. Для сайта с 20-30 заявками в месяц это ничего не меняет, для магазина с рекламным бюджетом пять минут в час пик уже ощутимы.
Ложные срабатывания убивают мониторинг быстрее, чем его отсутствие: после десятого ночного алерта ни о чём уведомления начинают игнорировать. Два правила снимают почти все ложные тревоги:
- Считать инцидентом только 2-3 неудачные проверки подряд, а не одну.
- Проверять минимум с двух географических точек. Одна точка регулярно ловит проблемы своего провайдера, а не вашего сайта.
Третий источник шума - защита самого хостинга: частые однотипные запросы с одного адреса выглядят как атака. Мы с этим сталкивались на своём проекте: сайт работает, а проверялка получает разорванное соединение. Лечится добавлением адресов сервиса в исключения через поддержку хостинга.
Куда приходит алерт и почему письмо ночью не работает
Уведомление на почту в три часа ночи не будит никого: телефон в беззвучном, почтовый клиент без звука, а утром письмо тонет среди рассылок. К моменту прочтения сайт либо поднялся сам, либо лежит шесть часов.
Рабочая схема:
- Telegram-бот в отдельном чате только под алерты, со включённым звуком именно для этого чата. Бесплатный минимум, который действительно работает.
- SMS или звонок робота для критичных сайтов: порядка 3-7 рублей за сообщение, зато будит.
- Эскалация. Не отреагировали за 15 минут - уведомление уходит второму человеку. Без этого схема держится на одном сотруднике, который может быть в самолёте.
- Уведомление о восстановлении обязательно, иначе через час никто не знает, чем всё кончилось.
Сайт открывается, а заявки не приходят
Это самая незаметная авария из всех, и мониторинг доступности её не видит: код ответа 200, страница на месте, форма отправляется и показывает "спасибо". А письмо не уходит.
Причины из практики: сменился пароль почтового ящика, хостинг ввёл лимит на исходящие, обновился плагин формы и потерял настройки, письма ушли в спам после смены IP сервера. Замечают такое через две-три недели по подозрительной тишине.
Что с этим делать:
- Автопроверка доставки. Раз в сутки скрипт отправляет тестовую заявку с меткой и через несколько минут проверяет, что она появилась в почте, таблице или CRM. Нет записи - алерт.
- Дублирование канала. Заявка должна уходить в два места сразу: почта плюс Telegram или почта плюс таблица.
- Контроль по количеству. Обычно 4-6 обращений в день, а за двое суток ноль - повод проверить форму даже без технической ошибки.
- Проверка SPF, DKIM и DMARC после переезда на другой сервер: половина случаев "письма не доходят" сводится к спам-фильтрам.
Сколько стоит простой в вашем случае
Считать проще всего от среднего дня: выручку сайта за месяц разделить на число рабочих дней и прикинуть долю потерянного времени.
Пример из практики. Магазин с выручкой около 900 000 рублей в месяц через сайт и маржой порядка 25%: средний день дает 40 000 рублей выручки и 10 000 рублей маржи, четыре дневных часа простоя стоят около 4 000 рублей упущенной прибыли. Сверху реклама: при бюджете 60 000 рублей в месяц за те же часы примерно 300 рублей уходят на клики по лежащему сайту. Мониторинг за 1 000 рублей в месяц окупается первым же инцидентом.
Бывает и обратное. Сайт-визитка стоматологии без рекламы, 2-3 заявки в неделю, основной поток идёт с карт и по рекомендациям: простой в ночь на воскресенье не стоит ничего. Здесь хватит бесплатного пятиминутного мониторинга, платить не за что.
Что настроить за один вечер
Порядок действий, который закрывает большинство случаев:
- Завести аккаунт в бесплатном внешнем сервисе, добавить главную и 2-3 важные внутренние страницы.
- Включить проверку по ключевому тексту, а не только по коду ответа.
- Подключить уведомления в отдельный Telegram-чат со звуком, почту оставить как дубль.
- Добавить проверки сертификата и домена с порогами 14 и 30 дней.
- Настроить условие "2 неудачные проверки подряд" и минимум две точки проверки.
- Убедиться, что бэкап создаётся и весит столько же, сколько неделю назад.
- Отправить тестовую заявку через каждую форму и поставить в календаре повтор через неделю.
- Записать, кто получает алерт, кто второй в очереди и куда звонить в хостинг. Если сайт ведёт подрядчик, дежурство обычно входит в техподдержку и отдельно настраивать ничего не нужно.
Первые десять минут после алерта. Убедиться, что сайт лежит для всех, а не только у вас: открыть с мобильного интернета и через сторонний сервис проверки. Дальше панель хостинга: свободное место и нагрузка. Затем домен и сертификат. Если причина не нашлась, идти по порядку из статьи Сайт не работает: 9 причин и пошаговая диагностика.
Когда это окупается и что делать дальше
Мониторинг не предотвращает аварии, он сокращает время, пока о них никто не знает. Разница между "лежало 6 часов" и "лежало 20 минут" измеряется деньгами и заметна уже на первом инциденте. Базовый набор из внешней проверки, алертов в мессенджер и контроля сроков домена с сертификатом настраивается за вечер и не требует бюджета. Отдельно стоит закрыть слепую зону с формами: она обходится дороже всего, потому что тишина не выглядит как поломка.
Если возиться с настройкой некогда, мониторинг и реакцию на инциденты мы берём на себя в рамках поддержки сайта: проверки, алерты, дежурство и разбор причины после каждого падения. Начать можно с одного контроля доступности, без остальных работ.
