Sentry — не безымянный uptime-бот, а известная платформа мониторинга ошибок и производительности приложений (APM), которой пользуются десятки тысяч команд разработки по всему миру. Функция Uptime Monitoring — сравнительно новое дополнение к основному продукту: она вышла в открытую бету в рамках существующей платформы и позволяет клиентам Sentry настраивать проверку доступности своих же URL прямо из того же интерфейса, где они отслеживают ошибки и трассировки.
Как это устроено технически и почему это не «просто ещё один uptime-чекер»
Официальная документация Sentry подробно описывает механику: система проверки доступности выполняет HTTP-запросы к заданным URL с заранее настроенными интервалами (по умолчанию — раз в минуту), а успешным считается ответ с кодом из диапазона 200–299, хотя эту логику можно кастомизировать. Ключевая техническая деталь, отличающая этот бот от большинства остальных мониторинговых ботов этой серии, — интеграция с трассировкой запросов: каждый uptime-чекер по умолчанию несёт заголовок Sentry-Trace, и если проверка обнаруживает простой, созданная в системе Uptime Issue связывается с трассировкой запроса, позволяя разработчику сразу увидеть не просто факт падения сайта, а конкретные ошибки и цепочку вызовов, которые к этому привели.
Параметры бота
| Параметр | Значение |
| User-Agent | SentryUptimeBot/1.0 (+http://docs.sentry.io/product/uptime-monitoring/) |
| Оператор | Sentry — платформа мониторинга ошибок и производительности приложений |
| Официальная документация | docs.sentry.io/product/uptime-monitoring/troubleshooting/ |
| Частота по умолчанию | Проверка каждую минуту, если не задано иначе в настройках конкретного монитора |
| Настраиваемость запроса | Клиент Sentry может задать HTTP-метод (GET, POST, HEAD, PUT, DELETE, PATCH, OPTIONS), собственные заголовки и параметры тела запроса — то есть проверка не ограничена простым GET к главной странице |
| Список IP-адресов | ✅ Официально публикуется отдельная страница с полным списком диапазонов, используемых для uptime-проверок |
| Официальная рекомендация по верификации | Из-за того, что IP-адреса могут меняться без предупреждения, сама компания рекомендует проверять запрос в первую очередь по строке User-Agent, а не полагаться исключительно на список IP |
| Особенность классификации | По независимой категоризации Cloudflare Radar, у бота отдельно указан тип доступа «intermediary» — то есть его активностью управляет не только сам оператор Sentry напрямую, но и конечные пользователи платформы, настраивающие мониторы |
Важная деталь: бот может увеличивать счётчик ошибок в самом Sentry, если сайт тоже его клиент
Отдельная техническая тонкость, прямо описанная в официальной документации: если сайт сам использует Sentry SDK для отслеживания ошибок, запросы uptime-бота по умолчанию тоже попадают в общую квоту транзакций и трассировок — то есть проверки доступности могут «съедать» часть лимита мониторинга, выделенного на реальный пользовательский трафик. Компания прямо рекомендует клиентам, которые хотят избежать этого, фильтровать события по User-Agent бота на стороне своего SDK, чтобы не отправлять эти технические проверки в общую статистику.
Подключите домен и посмотрите живую ленту: кто пришёл, с какой сети, что запрашивал и по какому правилу был пропущен или заблокирован.
Сколько трафика он создаёт
По независимому описанию, трафик от этого бота «регулярен, как cron-задача, — потому что обычно им и является»: uptime-мониторы обращаются к одному и тому же эндпоинту каждые несколько минут, а не системно обходят весь сайт. Это узкий, повторяющийся паттерн, принципиально отличный от системного краулинга.
Как найти бота в логах и проверить подлинность
grep -i "SentryUptimeBot" /var/log/nginx/access.logОфициальный список IP-диапазонов доступен на отдельной странице документации Sentry (IP Ranges) — но, учитывая собственную рекомендацию компании о возможных изменениях без предупреждения, сверка по строке User-Agent остаётся основным методом верификации.
Стоит ли блокировать
- если мониторинг настроен вашей же командой через Sentry — бота нужно явно разрешить и, если сайт тоже отправляет данные в Sentry, отдельно настроить фильтрацию его трафика в собственном SDK, чтобы не искажать статистику ошибок;
- если мониторинг настроил кто-то посторонний (партнёр или интегратор, которому передали URL для тестирования производительности) — стоит уточнить внутри команды, прежде чем блокировать;
- официальная документация Sentry отдельно предупреждает: часть хостинг-платформ может ошибочно блокировать эти запросы через собственный файрвол, что приводит к ложным алертам о простое, — если сайт неожиданно получает такие алерты, стоит в первую очередь проверить настройки файрвола, а не сразу подозревать реальную проблему с доступностью.
Как настроить доступ
Явное разрешение, если это ваш мониторинг:
User-agent: SentryUptimeBot
Allow: /Запрет с дублированием на уровне сервера, если мониторинг чужой и нежелателен:
User-agent: SentryUptimeBot
Disallow: /if ($http_user_agent ~* "SentryUptimeBot") {
return 403;
}На позиции в поисковой выдаче Google, Bing или Яндекса присутствие или отсутствие этого бота не влияет.
Частые вопросы
SentryUptimeBot связан с трассировкой ошибок?
Может ли этот бот повлиять на статистику ошибок, если сайт тоже клиент Sentry?
С какой частотой бот проверяет сайт по умолчанию?
Можно ли настроить не только GET-запрос для проверки?
Почему сайт может получать ложные алерты о простое от Sentry?
Достаточно ли официального списка IP для верификации?
Команда TrafficVeil разрабатывает инструменты защиты сайтов от ботов, DDoS и веб-атак. Разборы ботов пишем по логам подключённых доменов и открытым данным операторов.