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

Мониторинг у вас уже "есть", а о падении снова узнаёте из WhatsApp клиента. В 23:40 Telegram-бот в mute "из‑за ложных down", письмо в спаме, коллега кидает ссылку на публичный детектор "у всех падает" – а у вас глюк хостинга. За один вечер усилите цепочку "падение → подтверждение → один алерт → эскалация → recovery", чтобы уведомление если сайт недоступен пришло раньше клиента и без шторма дублей.

Узнать, что сайт упал, – это рабочая доставка сигнала, а не галочка "мониторинг включён". Нужны минимум два канала (Telegram + email), правило "один подтверждённый инцидент = один первичный алерт", лестница эскалации и тест, что пуш реально дошёл. Публичный outage-detector отвечает "у всех ли в стране", ваш HTTP-check – "жив ли мой URL".

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

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

Отделите публичный детектор сбоев от личного алерта

В выдаче по запросам про уведомления часто первым идёт публичный детектор массовых сбоев (в духе Detector404): "не работает ли сервис у всех в регионе". Это полезно для triage, но это не ваш личный push о своём магазине. Личный мониторинг бьёт HTTP(S) по вашему URL раз в 1–5 минут; публичный детектор агрегирует жалобы по чужим сервисам. Путать их – снова ждать WhatsApp, пока "у всех" не про ваш хостинг. Отдельно: просроченный SSL даёт HTTP 200, но браузер блокирует клиентов – это не "сайт упал" в uptime-check.

Делать: на вопрос "у всех ли?" – внешняя точка и детектор; на вопрос "узнаю ли я о своём сайте?" – свой check + каналы. Не делать: считать подписку на чужой outage-лентой заменой алерту на ваш URL.

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

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

Отдельно: Яндекс Директ отключает объявления, если главная недоступна дольше ~15 минут, и может прислать email. Это защита рекламного бюджета, не замена личному алерту. Пока Директ ждёт, заказы уже теряются – нужен свой check раз в 1–5 минут и push на телефон.

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

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

Подключение email, Telegram-бота и webhook с выбором уровней инцидентов

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

Правило минимума: два канала параллельно. Например, Telegram ловит внимание, email страхует. Webhook – когда есть чат разработки: PingMap и PerfMon шлют down и recovery в несколько каналов; в recovery полезно видеть длительность. В тексте алерта – URL, статус, время и локация. Сухой "Site is down" без адреса – повод открыть не тот сайт.

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

Пример письма-алерта: тип проверки, серьёзность и ссылка в кабинет

Настройте антишум: один инцидент – один первичный алерт

Детали инцидента с рекомендуемыми действиями и mute на время работ

Шторм ложных и повторных down убивает доставку сильнее, чем редкий пропуск: после третьей ночной паники канал глушат. Практики 2026 (Dotcom-Monitor, PerkyDash, uptime-боты, Zabbix) сходятся:

• Не алертить с одной неудачи – подождите 2–3 подряд (consecutive failures) и/или подтверждение с двух геолокаций.
• Один подтверждённый инцидент = один первичный "down". Пока сайт лежит, не слать тот же down каждые 30 секунд.
• Still-down – редкое напоминание ("всё ещё лежит, 20 минут"), не спам. Cooldown на однотипные события; смена состояния DOWN↔UP всегда проходит.
• На деплой включайте maintenance window. Mute бота "навсегда" – антипаттерн: чините правило, не глушите канал.

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

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

Делать: consecutive failures + cooldown + recovery. Не делать: mute канала из-за шумного правила.

Соберите лестницу эскалации до звонка хостеру

Алерт без плана – "увидели и разошлись". Заранее закрепите в чате:

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

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

Настройте и протестируйте алерты без паники команде

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

1. Выберите внешний HTTP(S)-check главной и, если есть магазин, URL корзины или оформления.
2. Подключите Telegram: бот + chat ID. Отправьте тестовое сообщение руками.
3. Подтвердите email: уберите из спама, добавьте отправителя в доверенные.
4. По желанию добавьте webhook (down / recovery; у ряда сервисов – HMAC-подпись на HTTPS).
5. Включите правило: алерт после 2–3 подряд неудач; при наличии – две локации.
6. Тест без паники: отдельный chat ID или предупредите команду; на 3–5 минут отдайте 500 / остановите check – убедитесь, что пуш и письмо пришли, затем recovery.
7. Если алерт не пришёл: mute, spam, бот не кикнут, chat ID, второй канал, статус провайдера (/status/ или аналог).

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

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

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

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

1. Второй канал к уже существующему мониторингу (обычно Telegram).
2. Правило "один инцидент – один primary down" + consecutive failures.
3. Тестовый down в отдельном чате и проверка, что пуш не в mute.
4. Закреплённый чеклист ack → triage → хостинг → CMS-dev.

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

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