Как узнать, что сайт упал, до звонка клиента

В пятницу вечером клиент пишет в WhatsApp: "корзина не открывается". Вы открываете почту – письмо от мониторинга час назад лежит в "Спаме". Telegram-бот "не подключали, чтобы не бесило". К утру потеряны заказы. За 15–20 минут вы настроите цепочку "падение → подтверждение → пуш", чтобы узнавать о недоступности раньше звонка, без шума ложных "down" и с понятным планом реакции.

Узнать, что сайт упал, – это не разовая проверка "сейчас онлайн?", а доставка сигнала до телефона. Минимум два канала (Telegram + email), правило "не алертить с одного фейла" и чеклист первых 15 минут. Разовая диагностика – отдельно; setup мониторинга на Битрикс – тоже отдельно. Здесь ядро: чтобы пуш пришёл раньше клиента.

Речь про сайт на своём хостинге, в том числе на CMS "1С-Битрикс: Управление сайтом". Это не CRM Bitrix24. Если нужно прямо сейчас понять, у вас проблема или у всех, откройте чеклист проверки работоспособности. Если нужен полный setup мониторинга под Битрикс – есть гайд по настройке мониторинга. Ниже – как не узнавать о падении от покупателя.

Типичный провал не в том, что "мониторинга нет", а в том, что мониторинг есть, а сигнал не доходит: письмо в спаме, бот выключен, ложные алерты утомили команду. На Хабре HostTracker фиксировал: больше 70% оповещений уходят на email – канал "обязательный", но слабый как единственный. Результат правильной настройки: пуш на телефон раньше клиента. Цель – сделать доставку рабочей, а не выбрать "самый красивый" uptime-бренд.

Поймите, почему сигнал от клиента – плохой KPI

Если первый источник правды о даунтайме – чат продаж, вы уже опоздали. Пока клиент пишет, витрина или корзина недоступны: уходят заказы, падает доверие, ночью никто не чинит. При заявленном SLA 99.9% "бюджет" простоя в месяц – порядка 43 минут. Час в спаме съедает этот бюджет целиком.

На практике мониторинг без доставки – декорация. HTTP-check зелёный в кабинете, а телефон молчит. Или наоборот: сыплются ложные "сайт упал" при коротком сетевом глюке, и команда выключает уведомления "навсегда".

Делать: считать KPI "время до первого надёжного алерта", а не "есть ли галочка мониторинга". Не делать: считать, что "почта подключена = мы в курсе".

Выберите каналы: Telegram, email и webhook

Канал – это не "куда сервис умеет слать", а "куда вы реально смотрите в 23:40". Три рабочих варианта для владельца без DevOps:

Например, правило минимума: два канала параллельно. Telegram ловит внимание, email страхует, если мессенджер молчит. Webhook – когда есть чат разработки или нужно дернуть скрипт. Сервисы вроде PingMap и Tracker.ru как раз шлют down и recovery в несколько каналов сразу; в recovery полезно видеть длительность простоя – так проще понять масштаб.

В тексте алерта должны быть URL, статус (down / recovered), с какого времени и, по возможности, с какой локации. Сухой "Site is down" без адреса – повод открыть не тот сайт.

Делать: подключить Telegram + email в первый же вечер. Не делать: оставлять только почту "для галочки".

Отсейте ложные срабатывания от реального даунтайма

Типичная ошибка – глушить канал после ложных down. Ложный "down" опаснее редкого пропуска: после третьей ночной паники алерты выключают. Практики 2026 года (Dotcom-Monitor, StatusPage.me, PingMap) сходятся:

• Не алертить с одной неудачной проверки – подождите 2–3 подряд (consecutive failures).
• Подтверждайте сбой с двух и более геолокаций, если сервис это умеет.
• На деплой и плановые работы включайте окно обслуживания (maintenance), чтобы не разбудить команду осознанно.
• Таймаут слишком короткий = шум; слишком длинный = опоздание. Начните с разумного дефолта сервиса и подкрутите после недели логов.

Отдельно: HTTP 200 на главной не значит, что оформляется заказ. Если бизнес-критична корзина или checkout – мониторьте и её (отдельный URL или сценарий). Иначе узнаете о "тихом" падении снова от клиента.

Схема антишума:
Внешний check → 2–3 неудачи подряд и/или 2 локации → алерт в Telegram + email → recovery с длительностью → (при деплое) maintenance window

Делать: включить подтверждение и окно обслуживания. Не делать: глушить канал целиком из-за одного шумного правила.

Настройте алерты пошагово без шума

Ниже минимум без DevOps. Конкретный бренд uptime не важен – важны check, каналы и тест. Если используете BX Pulse, уведомления Telegram / email / webhook и публичный статус сервиса уже в продукте; подключение обычно укладывается примерно в 15 минут.

1. Выберите внешний HTTP(S)-check главной страницы и, если есть магазин, URL корзины или оформления заказа.
2. Подключите Telegram: бот + chat ID (личный чат или группа дежурства). Отправьте тестовое сообщение руками.
3. Подтвердите email: уберите письмо из спама, добавьте отправителя в доверенные, проверьте, что письмо приходит на телефон.
4. По желанию добавьте webhook в рабочий чат команды (JSON down / still-down / recovered).
5. Включите правило: алерт только после 2–3 подряд неудач; при наличии – проверка из двух регионов.
6. Сделайте тестовый инцидент: временно отдайте 500 на тестовом URL или остановите check-цель на 3–5 минут – убедитесь, что пуш и письмо пришли.
7. Задайте "тихие" окна только для плановых работ, не на все ночи "чтобы спать".

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

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

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

Пройдите чеклист реакции на инцидент

Алерт пришёл – первые 5–15 минут решают, будет ли это "быстрый фикс" или час хаоса.

1. Ack: отметьте, что увидели сигнал (в чате или в кабинете). Не молчите "потом посмотрю".
2. Быстрый triage: локально у вас или у всех? Коротко по проверке работоспособности – инкогнито / LTE и одна внешняя точка.
3. Эскалация: хостинг (код, время, URL) и/или разработчик CMS. Для Битрикс-специфики – мост к мониторингу на Битрикс.
4. Дождитесь recovery, затем пять минут постмортема: что сломалось, почему алерт поздно или шумно, что поправить завтра.

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

Что сделать дальше сегодня вечером

Короткий план на один вечер:

1. Второй канал к уже существующему мониторингу (обычно Telegram).
2. Правило consecutive failures или multi-region.
3. Тестовый down и проверка, что пуш не в mute.
4. Закреплённый чеклист реакции с контактами хостинга.

Если setup на стороне Битрикс ещё сырой – откройте гайд по мониторингу на CMS; если "упало прямо сейчас" – чеклист triage.

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

Материал проверен. Автор: Максим Мольков, основатель BX Pulse, инженер по эксплуатации 1С-Битрикс.
Источники: HostTracker на Хабре (каналы оповещений), PingMap: alerts, Tracker.ru Telegram, Dotcom-Monitor alerts best practice, Hyperping: 99.9% downtime budget, mpns.by: алерты по событиям.