Миф: проверки доступности раз в пять минут достаточно

MAATRIX

Настроили мониторинг, выбрали интервал проверки в 5 минут — потому что так по умолчанию стоит почти в любом инструменте — и на этом успокоились: сайт под присмотром, о падении узнаем автоматически. Проблема в том, что «5 минут» — это не инженерный расчёт под ваш сервис, а исторический дефолт бесплатных тарифов мониторинга, и для многих проектов этого интервала откровенно мало. Разберём, сколько реально стоит такая частота проверки в минутах непойманного простоя и как подобрать интервал, который соответствует именно вашей цене простоя, а не чужому дефолтному значению.

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

Пятиминутный интервал — это не результат чьих-то расчётов оптимальной частоты, а компромисс, который сложился по коммерческим причинам у провайдеров внешнего мониторинга. Бесплатный тариф UptimeRobot долгие годы был построен именно на интервале в 5 минут — это лимит, который отличал бесплатный уровень от платного, где интервал становится короче. У аналогичных сервисов похожая логика: чем чаще проверка, тем выше нагрузка на инфраструктуру мониторинга и тем дороже план. Пять минут исторически стали негласным «стандартом по умолчанию» просто потому, что это самый частый первый опыт с мониторингом доступности вообще — бесплатный тариф, куда вписывают URL и забывают.

Дальше срабатывает эффект якоря: значение по умолчанию воспринимается как достаточное, потому что «раз оно стоит по умолчанию — значит, кто-то посчитал, что этого хватает». На деле никто не считал именно под ваш сервис — тариф считал экономику самого сервиса мониторинга, а не риск вашего простоя. Self-hosted инструменты вроде Uptime Kuma в этом смысле честнее: интервал там ничем не ограничен технически, а дефолт в панели — просто стартовое значение, которое стоит менять под задачу, а не считать рекомендацией.

Сколько реально проходит за пять минут незамеченным

Ключевая ошибка в восприятии интервала — считать, что «проверка раз в 5 минут» означает «максимум 5 минут простоя останется незамеченным». На практике всё хуже, и вот почему.

Возьмём худший случай: сайт упал через секунду после успешной проверки. Следующая проверка — только через 5 минут, и лишь тогда система узнает о проблеме. Дальше — задержка на подтверждение: большинство инструментов не бьёт тревогу после первого неудачного запроса (это правильная защита от ложных срабатываний из-за короткого сетевого всплеска), а ждёт 2-3 неудачные проверки подряд. При интервале в 5 минут и пороге в 2 неудачные попытки это ещё +5 минут. Итого: от момента реального падения до момента, когда система решает, что сайт лежит, может пройти 10-15 минут — и это без учёта времени на то, чтобы дежурный человек увидел алерт, открыл ноутбук и начал разбираться.

худший случай = интервал × (1 + порог_срабатывания) + время реакции человека
            = 5 мин × (1 + 2) + человеческая реакция
            ≈ 15 минут до начала разбора, если повезёт с быстрой реакцией

15 минут — это не абстракция, это тот же порядок величины, что и весь месячный бюджет простоя при SLA в 99,9% (около 43 минут в месяц — подробный разбор арифметики «девяток» есть в статье про миф о том, что 99,9% аптайма — это почти всегда). Одно падение с пятиминутным интервалом проверки и типовым порогом срабатывания способно съесть треть месячного лимита простоя за один эпизод — и это ещё до того, как кто-то начал чинить проблему, а не после.

Отдельный случай — короткий, но полный простой, который целиком укладывается между двумя проверками. Сервис упал, автоматически перезапустился (systemd с Restart=always, Kubernetes с readiness-пробой, супервизор процесса) и снова отвечает 200 к моменту следующей проверки — история осталась только в логах приложения, если их вообще смотрели. Для личного блога это не страшно. Для платящих клиентов, у которых в этот момент сорвался запрос к API или не прошёл платёж, — это реальный инцидент, о котором вы узнаете постфактум из тикета в поддержку, а не из мониторинга, который должен был предупредить первым.

Почему это особенно критично для высоконагруженных и платящих клиентов

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

Для высоконагруженного проекта каждая минута простоя — это не тишина, а активный трафик, который в этот момент получает ошибки: пользователи жмут «обновить», получают 502, часть уходит сразу, часть создаёт лишнюю нагрузку повторными запросами в момент, когда сервис и так на грани. Чем выше трафик, тем больше людей успевает столкнуться с проблемой за те же 10-15 минут — а значит, тем больше шанс, что кто-то из них напишет в соцсети раньше, чем ваш мониторинг вообще узнает о падении.

Для сервиса с платящими клиентами добавляется прямая денежная составляющая: сорванные платежи, не отработавшие вебхуки, клиенты, чьи собственные интеграции с вашим API отваливаются и создают уже их инцидент, а не только ваш. Методика расчёта, во что обходится минута простоя конкретно вашему проекту, разобрана в статье как посчитать цену простоя для B2B-сервиса — если минута простоя стоит заметных денег, экономия на интервале проверки в пользу бесплатного тарифа мониторинга — решение не туда, где нужно экономить.

Есть и более коварный сценарий: пиковая нагрузка совпадает с деградацией, а не с полным падением. Сервис не лежит целиком — он отвечает медленно, часть запросов проходит с таймаутом, часть успевает. Простая HTTP-проверка «код ответа 200» в такой ситуации может пройти успешно, потому что сама проверка — один лёгкий запрос без нагрузки, а не срез реального пользовательского опыта. При интервале в 5 минут окно, в котором такая деградация начинается и заканчивается незамеченной, оказывается ещё шире, чем при полном падении.

Соотнесите частоту проверки с реальным SLA и ценой простоя

Правильный вопрос — не «какой интервал стоит по умолчанию», а «сколько минут необнаруженного простоя я готов допустить, прежде чем система об этом узнает». Ответ напрямую вытекает из двух чисел: заявленного (или желаемого) SLA и реальной цены минуты простоя для бизнеса.

Если ваш SLA — 99,9%, это около 43 минут допустимого простоя в месяц (расчёт и таблица «девяток» — в уже упомянутой статье про миф про 99,9%). Если один необнаруженный эпизод из-за медленного мониторинга съедает 15 минут этого бюджета, у вас формально остаётся меньше трети лимита на все остальные, уже не связанные с мониторингом причины простоя — плановые работы, чужие сбои у апстрима, редкие аппаратные проблемы. Чем жёстче заявленный SLA, тем меньше в нём места для собственной медлительности обнаружения, и тем более безрассудно оставлять интервал проверки на дефолтных 5 минутах.

Второй параметр — цена простоя, а не только SLA-проценты. SLA описывает контрактную гарантию, а не то, что реально теряет бизнес: компенсация по SLA почти никогда не покрывает фактический ущерб, она привязана к стоимости самой услуги, а не к последствиям для вашего проекта. Если час простоя обходится вашему проекту в сумму, сопоставимую с ценой самой инфраструктуры за неделю, — экономия на более частом мониторинге ради пары свободных долларов в месяц выглядит нерационально мелочной. Если же простой сайта-визитки без прямых продаж стоит разве что неловкости при неудачном визите клиента — пятиминутный интервал и вовсе избыточная осторожность, тонкая настройка тут не окупает потраченного на неё времени.

Практический ориентир по интервалам, отталкиваясь от цены простоя:

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

Оборотная сторона: частая проверка — тоже нагрузка и тоже стоимость

Частить с проверками бездумно — такая же ошибка, как слепо держать дефолтные 5 минут. У более короткого интервала есть своя цена, и её тоже нужно учитывать, а не просто ставить минимально возможное значение «на всякий случай».

Первая статья расходов — нагрузка на сам проверяемый сервис. Каждая проверка — это реальный HTTP-запрос (а если это keyword-проверка контента или проверка через авторизацию — запрос ещё и не самый лёгкий). На большом парке мониторов, особенно если проверяется не один URL, а десятки эндпоинтов с разной логикой, суммарная нагрузка от мониторинга становится заметной статьёй трафика и CPU — это стоит учитывать, если интервал уходит в единицы секунд сразу на множестве целей.

Вторая статья — стоимость и лимиты самого инструмента мониторинга. У внешних SaaS-сервисов частота проверки почти всегда напрямую завязана на тариф: более короткий интервал требует более высокого (и более дорогого) плана, потому что провайдер мониторинга сам платит за инфраструктуру, которая чаще стучится к вашим URL. При self-hosted варианте вроде Uptime Kuma формального лимита по интервалу нет, но нагрузка на сервер, где стоит сам мониторинг, растёт вместе с числом мониторов и частотой — на большом количестве целей с секундными интервалами это тоже упирается в ресурсы конкретного VPS, и стоит заранее прикинуть, оправдан ли для вашего масштаба свой стек или проще остаться на готовом сервисе.

Третья, менее очевидная статья — шум и усталость от ложных срабатываний. Чем короче интервал и чем ниже порог количества неудачных проверок перед алертом, тем выше риск, что короткий сетевой всплеск на пару секунд или разовый таймаут апстрима будет интерпретирован как падение и разбудит дежурного ради проблемы, которой уже нет к моменту, когда он открыл ноутбук. Без разумного порога срабатывания короткий интервал создаёт даже больше проблем, чем длинный: система реагирует на обычный сетевой шум вместо реальных инцидентов, и рано или поздно дежурный начинает игнорировать алерты просто потому, что они слишком часто оказываются пустыми. Здоровый баланс — короткий интервал плюс адекватный порог подтверждения (2-3 подряд неудачные проверки), а не алерт с первой же неудачи.

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

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

1. Посчитайте допустимый месячный простой из вашего SLA (своего заявленного или желаемого) по формуле 8760 × (1 − X/100) / 12 часов в месяц, переведите в минуты. Это верхняя граница, с которой соотносится всё остальное.
2. Оцените реальную цену минуты простоя для вашего проекта — не абстрактно, а в деньгах и репутации: сколько заказов, платежей, обращений в поддержку и репутационного ущерба генерирует минута недоступности в типичный, а не в самый тихий час.
3. Выберите интервал так, чтобы худший случай обнаружения (интервал × порог срабатывания + время реакции) укладывался в заметно меньшую долю допустимого месячного простоя, а не съедал его целиком за один эпизод. Ориентир — необнаруженный простой от одного инцидента не должен превышать 10-20% месячного лимита по SLA.
4. Проверьте, что выбранный интервал не упирается в лимиты тарифа или ресурсы своего сервера — короткий интервал на дешёвом бесплатном плане внешнего сервиса технически может быть недоступен, а на self-hosted решении может создавать заметную нагрузку при большом числе целей.
5. Настройте разумный порог подтверждения (обычно 2-3 неудачные проверки подряд) вместо алерта с первого же сбоя — это не противоречит короткому интервалу, а дополняет его: короткий интервал ловит проблему быстро, порог подтверждения не даёт системе паниковать от каждого сетевого всплеска.
6. Пересматривайте интервал при росте проекта. Сервис, который начинался как лендинг с редким трафиком и жил на 5-минутном мониторинге, спустя год может превратиться в SaaS с платящими клиентами — а настройки мониторинга часто остаются нетронутыми с момента первого запуска, потому что «работает же». Дефолт, разумный на старте, годы спустя оказывается той же самой непроверенной привычкой, с которой мы начали.

Отдельно стоит убедиться, что сама проверка доступности видит реальную картину, а не проходит мимо проблемы формально: HTTP-код 200 не гарантирует, что страница реально отдаёт нужный контент, а проверка через кеширующий CDN иногда продолжает получать «200 OK» от кеша даже тогда, когда сам источник за ним уже недоступен — конкретный случай такой ловушки разобран в статье проверка доступности ходила через кеш CDN и не видела падения. Частый интервал бесполезен, если проверка технически не способна заметить реальную проблему — сначала чиним, что именно проверяется, потом — как часто.

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