Оповещения о недоступности

Как получать уведомления о падении сайта и правильно на них реагировать

Разбираем, что считать падением сайта, какие страницы и API нужно контролировать, когда создавать инцидент и как убедиться, что сообщение о проблеме действительно было отправлено.

Создать аккаунт Открыть материалы

Уведомления о падении сайта и восстановлении в UpWatch

Краткий ответ

Чтобы получать полезные уведомления о падении сайта, недостаточно проверять только главную страницу. На мониторинг нужно поставить критичные URL: главную, страницу входа, оплату, API или другой endpoint, отказ которого мешает пользователям.

Уведомление должно сообщать как минимум о начале инцидента и о восстановлении. Для быстрой реакции можно использовать Telegram или MAX, а email оставить дополнительным и архивным каналом.

Само отсутствие сообщения ещё не доказывает, что мониторинг не сработал. Нужно проверить состояние монитора, настройки событий, подключение канала, тихие часы и историю попыток доставки.

Почему сайт может быть частично недоступен

Фраза «сайт упал» объединяет несколько разных ситуаций. Для каждой из них нужен отдельный монитор.

Не открывается весь сайт

Домен не разрешается, соединение не устанавливается, сервер не отвечает либо возвращает ошибку на всех страницах.

Не работает критичная страница

Главная доступна, но пользователь не может войти, оформить заказ, открыть оплату или воспользоваться другой важной функцией.

Недоступен API

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

Сервис отвечает, но слишком медленно

Пользователь воспринимает длительный ответ как недоступность, даже если итоговый HTTP-статус формально успешный.

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

Полезно понимать всю цепочку: от запуска проверки до сообщения в выбранном канале.

Этап 1

UpWatch запускает проверку

Монитор обращается к настроенному URL или endpoint-у с заданными параметрами.

Проверяется доступность адреса.
Учитывается HTTP-ответ.
Для API может дополнительно проверяться JSON.
Результат сохраняется в истории запусков.

Этап 2

Неуспешные проверки формируют инцидент

Инцидент отражает период проблемы, а не только одну строку в истории.

Фиксируется начало проблемы.
Последующие неуспешные запуски относятся к тому же инциденту.
В карточке можно увидеть связанные проверки.
После успешного результата фиксируется восстановление.

Этап 3

Система определяет нужные события и каналы

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

Включено ли уведомление о начале инцидента.
Включено ли уведомление о восстановлении.
Разрешён ли канал текущим тарифом.
Подключён ли адрес, чат или другой получатель.

Этап 4

Создаётся попытка доставки

Результат отправки или причина пропуска сохраняются для последующей диагностики.

Успешная отправка фиксируется в истории.
Ошибка внешнего провайдера отображается отдельно.
Штатный пропуск получает понятную причину.
Можно отличить проблему настройки от ошибки доставки.

Какой канал выбрать для уведомлений

Один универсальный канал подходит не всем. Надёжнее использовать каналы с разными назначениями.

Канал	Для чего подходит	Преимущества	Ограничения
Email	Базовые уведомления, личная почта, архив сообщений и команды без рабочего чата.	Не требует подключения мессенджера и подходит как исходный канал для начала работы.	Письмо может быть замечено не сразу, попасть в спам или задержаться на стороне почтового сервиса.
Telegram	Оперативная реакция команды в личном или групповом чате.	Сообщение быстро появляется в привычном рабочем канале.	Нужно подключить чат и сохранить боту возможность отправлять сообщения. Канал зависит от тарифа.
MAX	Команды, использующие MAX как основной рабочий канал.	Позволяет получать сообщения о начале и восстановлении инцидента в MAX.	Нужно корректное подключение чата и доступность канала на текущем тарифе.

Как настроить уведомления о недоступности

Сначала определите критичные точки сайта, затем настройте события и проверьте каждый канал.

Шаг 1

Выберите критичные URL

Поставьте на мониторинг не все страницы подряд, а те, отказ которых влияет на пользователей или деньги.

Главная страница.
Страница входа.
Страница оплаты.
Критичный API endpoint.
Healthcheck приложения.

Шаг 2

Настройте сами проверки

Для каждого URL определите нормальный ответ и допустимое время ожидания.

Укажите правильный адрес.
Выберите нужный HTTP-метод.
Настройте ожидаемый ответ.
Добавьте проверку JSON, если одного HTTP-кода недостаточно.

Шаг 3

Выберите события

Минимально полезный сценарий включает начало инцидента и восстановление.

Включите событие начала инцидента.
Включите событие восстановления.
Не создавайте лишние сообщения без операционной необходимости.
Учитывайте тихие часы.

Шаг 4

Проверьте каналы заранее

Не ждите первого настоящего падения, чтобы выяснить, работает ли доставка.

Выполните тестовую отправку.
Убедитесь, что сообщение появилось у получателя.
Проверьте историю тестовой доставки.
Исправьте ошибки подключения до запуска мониторинга.

Почему уведомление о падении могло не прийти

Проверяйте цепочку последовательно, а не ограничивайтесь повторным включением канала.

Симптом	Возможная причина	Что делать
Не было ни инцидента, ни уведомления	Монитор выключен, адрес проверяется неправильно либо результат не считается неуспешным.	Откройте историю запусков, проверьте состояние монитора, URL, ожидаемый ответ и параметры проверки.
Инцидент есть, но попытки доставки нет	Событие отключено, канал не выбран либо настройка отдельного монитора переопределяет общее правило.	Проверьте события начала и восстановления, настройки рабочего пространства и настройки конкретного монитора.
Доставка пропущена	Сработали тихие часы, ограничение тарифа, выключенный канал или другая штатная причина.	Откройте причину пропуска в истории доставки и исправляйте именно указанную настройку.
Отправка завершилась ошибкой	Провайдер отклонил сообщение, чат удалён, бот потерял доступ или внешний сервис не ответил вовремя.	Проверьте подробное описание ошибки, подключение получателя и выполните повторную тестовую отправку.
Уведомление отправлено, но человек его не увидел	Сообщение оказалось в неподходящем канале, письмо попало в спам или у команды нет ответственного.	Измените рабочий процесс: добавьте оперативный канал, определите ответственного и проверьте настройки получателя.

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

Большое количество сообщений не делает мониторинг надёжнее. Оно снижает внимание команды.

Мониторьте пользовательские сценарии

Ставьте отдельные проверки на вход, оплату, API и другие критичные точки вместо десятков второстепенных страниц.

Не отключайте восстановление

Команда должна понимать не только момент начала проблемы, но и момент, когда сервис снова стал доступен.

Используйте минимум два канала для критичных систем

Например, мессенджер для быстрой реакции и email для дополнительной фиксации сообщения.

Регулярно выполняйте тестовую отправку

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

Настраивайте тихие часы осознанно

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

Разбирайте причины пропуска

Не считайте любой пропуск ошибкой системы. История показывает, было ли это ожидаемым поведением или неисправностью.

Что UpWatch сохраняет для разбора инцидента

После события важно иметь не только сообщение в чате, но и данные, по которым можно восстановить хронологию.

История проверок

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

Период инцидента

Позволяет увидеть начало проблемы и момент восстановления.

Состояние отдельных каналов

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

Результат доставки

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

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

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

Частые вопросы

Когда UpWatch сообщает о падении сайта?

Уведомление формируется при начале инцидента, если соответствующее событие и канал включены и нет причины для штатного пропуска.

Приходит ли сообщение после восстановления?

Да, если событие восстановления включено в настройках уведомлений.

Почему главная работает, а монитор сообщает о сбое?

Инцидент может относиться к другой проверке: API, странице входа, оплате или отдельному endpoint-у.

Как узнать, почему сообщение не отправилось?

Нужно открыть историю доставки. В ней отображается результат попытки и причина ошибки или пропуска.

Какой канал выбрать для критичного сайта?

Для быстрой реакции полезен рабочий мессенджер. Email можно оставить вторым каналом и дополнительной фиксацией.

Нужно ли отключать уведомления ночью?

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

Связанные материалы

Дополнительные страницы помогут настроить отдельные каналы и разобраться с инцидентами.

Система уведомлений UpWatch

Подробно о каналах, событиях, тихих часах, тестах и истории доставки.

Telegram-уведомления

Как подключить Telegram и получать сообщения в личный или групповой чат.

Email-уведомления

Как использовать почту для сообщений о начале и восстановлении инцидента.

Инциденты

Как последовательные сбои объединяются в период проблемы и восстановления.

Настройте оповещения о недоступности

Добавьте критичные страницы и API, включите события начала и восстановления и проверьте доставку до первого реального инцидента.

Создать аккаунт Как работает мониторинг