Как часто нужно проверять сайт: замер по 140 мониторам и 489 инцидентам

Мы посмотрели, с какой частотой опрашиваются 140 активных мониторов в нашей системе на 27 августа 2026 года:

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

По типам проверок: HTTP 114 мониторов, ping 8, SSL 7, API 5, порт 2, DNS 2, домен 2.

Оговорка о выборке: это наши пользователи, а не рынок мониторинга. 140 мониторов — величина, на которой видны крупные различия и не видны тонкие.

За тот же период у нас закрылось 489 инцидентов с известной длительностью. Распределение:

Медиана — 45 минут. Но важнее хвост слева: каждый четвёртый сбой укладывается в пять минут, а больше трети — в десять.

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

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

То есть сорок процентов мониторов настроены так, что в среднем не заметят более сорока процентов сбоев. Не «заметят с опозданием» — не заметят вовсе: сбой начнётся и закончится между двумя проверками, и в истории не останется ничего.

Как считалась оценка и почему она оптимистична. Это расчёт, а не замер: предполагается, что сбой начинается в случайный момент цикла опроса. Реальность хуже по двум причинам. Во-первых, инцидент обычно объявляется не по первой неудаче, а после нескольких подряд — значит короткий сбой должен продержаться несколько интервалов, чтобы вообще попасть в статистику. Во-вторых, само распределение построено по сбоям, которые были замечены, — те, что уже пропущены редким опросом, в него не попали. Настоящая доля пропусков выше посчитанной.

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

1. Если важен сам факт доступности — витрина, лендинг, документация — часа достаточно. Многочасовое падение вы увидите, а пятиминутное вам, скорее всего, безразлично.
2. Если за сбой платят деньгами — оплата, корзина, API для клиентов — час не годится. Пять минут ловят 87% сбоев, минута — 98%.
3. Не смешивайте в одном интервале разное. У большинства проектов один-два по-настоящему критичных адреса и десяток второстепенных. Логично поставить минуту на первые и час на остальные, а не усреднять.
4. Проверьте порог объявления инцидента. Если он требует трёх неудач подряд, при часовом интервале сбой должен длиться три часа, чтобы вас уведомили. Это отдельная настройка, и о ней часто забывают.

Посмотреть, как это устроено, и завести свои проверки можно в мониторинге.