SDK может сообщить о проблеме, только пока приложение работает. Когда оно не работает — хост недоступен, прокси отвечает 502, истёк сертификат, — отправлять нечего. Мониторы доступности закрывают этот пробел: Buglapse со своих серверов с заданным интервалом запрашивает адрес, помечает монитор недоступным, когда запросы раз за разом не проходят, и сразу сообщает команде.

Мониторингу доступности не нужен SDK. Он работает для любого HTTP(S)-адреса — главной страницы, health check API, приёмника вебхуков — и для gRPC-серверов (см. gRPC-мониторы).

Создать монитор

Откройте проект, перейдите в Доступность и нажмите Новый монитор. Создавать, менять, приостанавливать и удалять мониторы проекта может любой участник организации. Кнопка Импорт cURL заполнит форму из команды curl — например, скопированной через «Copy as cURL» в браузере.

Поле	По умолчанию	Что делает
Название	—	Как монитор называется в списке и в алертах.
Тип	HTTP	HTTP или gRPC — см. gRPC-мониторы.
URL	—	Только http:// или https://, без user:password@.
Метод	GET	GET, HEAD, POST, PUT, PATCH, DELETE или OPTIONS.
Заголовки	нет	До 20 пар «имя — значение», например Authorization для защищённого health check. Host и Content-Length задаёт сам запрос.
Тело	нет	До 64 КБ, отправляется со всеми методами, кроме GET и HEAD.
Таймаут	10 с	1–30 секунд на всю проверку, включая редиректы.
Коды ответа, считающиеся успехом	200-299	См. Допустимые коды.
Следовать редиректам	вкл.	См. Редиректы.
Проверять каждые	5 мин	1, 5, 10, 20, 30 или 60 минут. Тариф может ограничить минимальный интервал.
Окружение	нет	Метка, например production, — видна в списке и в алертах.
Недоступен после сбоев	3	Сколько неудачных проверок подряд открывают инцидент. После сбоя следующая проверка — через минуту.
Работает после успехов	1	Сколько успешных проверок подряд закрывают его.
Предупреждать об истечении сертификата	14 дней	Только для https://: за сколько дней (1–90) до конца TLS-сертификата прислать алерт; пусто — не предупреждать. См. Срок сертификата.

Проверить выполняет одну проверку с текущими настройками формы и показывает результат — код ответа, время, ошибку, — ничего не сохраняя. Не больше 10 проверок в минуту.

Первая проверка выполняется в пределах выбранного интервала (мониторы, созданные вместе, разносятся во времени, чтобы не срабатывать в одну секунду). Пока вердикта нет, монитор в состоянии Ожидание.

Допустимые коды

Список кодов и диапазонов (включительно) через запятую, каждый от 100 до 599, не больше 20 элементов:

200-299, 301, 404

Ответ с любым другим кодом — сбой (Неожиданный статус). Разрешить 404 удобно для адреса, которого и не должно быть: важно лишь, что сервер отвечает.

Что делает проверка

• Отправляет метод, заголовки и тело монитора. Если вы не задали свой заголовок User-Agent, она представляется так:

  BuglapseUptime/1.0 (+https://app.buglapse.com)

  Пропустите его через WAF или защиту от ботов, если они проверяют незнакомых клиентов: страница проверки обычно отвечает кодом, который вы не разрешили.

• Cookie не отправляются и не сохраняются между проверками.

• Тело ответа читается не больше 64 КБ и отбрасывается; сохраняются только код ответа и время.

• Все проверки идут с серверов Buglapse, а не из нескольких регионов.

Редиректы

С включённым Следовать редиректам Buglapse проходит до 5 редиректов (301, 302, 303, 307, 308) и оценивает код последнего ответа; больше 5 — сбой (Слишком много редиректов). 303, а также 301/302 после POST, продолжаются как GET без тела, как в браузерах. Таймаут покрывает всю цепочку.

С выключенным оценивается код первого ответа как есть — так что добавьте 301 или 302 в допустимые коды, если редирект и есть ожидаемый ответ.

Почему проверка не проходит

Ошибка	Что значит
Неожиданный статус	Сервер ответил кодом, который вы не разрешили (показывается как HTTP 503 и т.п.).
Таймаут	Полного ответа нет в пределах таймаута.
Ошибка DNS	Имя хоста не разрешилось.
Нет соединения	Соединение отклонено или сброшено.
Сертификат истёк	Срок TLS-сертификата сервера закончился.
Ошибка TLS	Сертификат самоподписан или не соответствует хосту, либо не удалось TLS-рукопожатие.
Слишком много редиректов	Больше 5 редиректов.
Запрещённый адрес	Хост разрешается в частный или зарезервированный адрес — см. ниже.
Ошибка запроса	Всё остальное; журнал проверок показывает исходное сообщение.

Срок сертификата

Истёкший сертификат — простой, который видно заранее. Каждая проверка https://-адреса заодно читает TLS-сертификат сервера: когда он заканчивается, на какой хост выдан и кем. Если проверка прошла через редиректы на другие хосты, учитывается сертификат, который закончится раньше всех. Срок виден на странице монитора, а в списке монитор с сертификатом в пределах срока предупреждения помечен жёлтым («Сертификат истекает через 9 дн.»).

Когда до конца остаётся Предупреждать об истечении сертификата дней (по умолчанию 14), приходит алерт Сертификат истекает, а дальше ещё по разу на 7, 3 и 1 день (и на 30, если предупреждать раньше). Первое предупреждение — на той ступени, где срок уже находится: монитор, созданный за 5 дней до конца, сразу пришлёт «7 дней», а не всю цепочку. Продлённый сертификат (с новой датой окончания) начинает отсчёт заново, так что после продления предупреждения прекращаются сами.

Если сертификат всё же истёк, проверка падает с ошибкой Сертификат истёк, и монитор становится недоступным как обычно. Такой сбой никогда не считается незасчитанным: это проблема сервера, а не сети Buglapse.

Изменение URL, типа или настройки редиректов забывает сохранённый сертификат — следующая проверка прочитает его заново.

gRPC-мониторы

gRPC-сервер отвечает HTTP 200, что бы ни случилось, — настоящий результат — это grpc-status, который он присылает после ответа. Монитор типа gRPC делает один унарный вызов и оценивает этот статус:

• URL — адрес сервера: https://grpc.example.com:443 через TLS или http://grpc.internal:50051 открытым текстом (h2c). Вызов всегда идёт по HTTP/2.
• Пустой метод выполняет стандартный health check grpc.health.v1.Health/Check: монитор работает, пока ответ — SERVING. Сервис health check — сервис, о котором спрашивать; пустой — о сервере в целом.
• Заданный метод (package.Service/Method) вызывается вместо него. Сообщение запроса — сообщение в protobuf, закодированное в base64 (пустое отправляет пустое сообщение), а Допустимые gRPC-коды — список статусов от 0 до 16, по умолчанию 0 (OK), например 0, 5, чтобы разрешить ещё и NOT_FOUND.
• Заголовки отправляются как gRPC-метаданные, например authorization. content-type и te задаёт сам вызов; HTTP-метод, допустимые HTTP-коды и редиректы не применяются.

Закодировать сообщение запроса можно, например, через protoc:

echo 'id: 42' | protoc --encode=shop.GetOrderRequest shop.proto | base64

Журнал проверок показывает gRPC-статус (UNAVAILABLE и т.п.) в колонке кода, а сбои выглядят как gRPC UNAVAILABLE (14): upstream connect error. Собственные ошибки:

Ошибка	Что значит
Неожиданный gRPC-статус	Вызов завершился статусом, который вы не разрешили, — для health check любым, кроме OK (сервер без health-сервиса отвечает UNIMPLEMENTED).
Не обслуживает	Health check ответил NOT_SERVING, SERVICE_UNKNOWN или UNKNOWN.
Ответ не по gRPC	grpc-status не пришёл — по адресу не gRPC-сервер, или прокси перед ним не умеет HTTP/2.
Неожиданный статус	Ответ не HTTP 200 (показывается как HTTP 404 и т.п.).

Работает, недоступен, инциденты

Монитор становится недоступным после стольких неудачных проверок подряд, сколько задано в «Недоступен после сбоев», и это открывает инцидент. Инцидент начинается с первого сбоя серии, а не с проверки, перешедшей порог, — так его длительность совпадает с реальным простоем. Он закрывается после заданного числа успешных проверок подряд, в момент первой из них, и монитор снова работает.

Пока серия не дошла до порога, следующая проверка идёт через минуту, а не через интервал: монитор с проверкой раз в час при пороге 3 подтверждает падение за пару минут, а не за два часа. Так же перепроверяется и восстановление недоступного монитора, пока не набрано «Работает после успехов». Когда состояние подтверждено, проверки возвращаются к интервалу; минимальный интервал тарифа на перепроверки не действует.

Один неудачный запрос ниже порога инцидента не открывает: одиночный таймаут чаще случайность, чем падение. Снизьте порог до 1, чтобы узнавать о каждом сбое; повысьте «Работает после успехов», если сервис склонен мигать.

Незасчитанные проверки

Все проверки идут из одного места, поэтому проблема с исходящей сетью самого Buglapse сделала бы недоступными сразу все мониторы. Когда пачка проверок падает на сетевом уровне (таймаут, DNS, соединение, TLS), Buglapse дополнительно запрашивает заведомо рабочий адрес. Если и он не отвечает, эти проверки сохраняются как Не засчитана: они видны в журнале, но не считаются сбоями и не прерывают их серию. Проверка, получившая ответ с кодом, оценивается всегда — раз до вашего сервера дошли, сеть работает.

Страница монитора

• Доступность — успешные проверки ÷ оценённые (без незасчитанных) за последние 24 часа, 7 или 30 дней; там же суммарный простой (время инцидентов за период), число инцидентов, среднее и p95 время ответа.
• Полоса доступности — период в виде отрезков по 15 минут (24 ч), 2 часа (7 дней) или 1 день (30 дней): зелёный, если все проверки прошли, жёлтый или красный — если часть или большинство упали, серый — без проверок. Наведите на отрезок, чтобы увидеть числа.
• Время ответа — среднее по отрезкам.
• Сертификат — у https://-монитора: сколько дней осталось и дата окончания (жёлтым — в пределах срока предупреждения); наведите, чтобы увидеть хост и издателя.
• Инциденты — начало, конец, длительность и причина каждого простоя; текущий выделен.
• Журнал проверок — каждая проверка с результатом, кодом, длительностью и ошибкой, с фильтром по результату.

Список мониторов показывает недоступные первыми, с доступностью каждого за последние 24 часа.

Алерты

У мониторинга доступности три типа алертов:

Тип	Когда
Монитор недоступен	Монитор стал недоступен — раз на инцидент.
Монитор восстановился	Он снова работает — раз на инцидент.
Сертификат истекает	TLS-сертификат заканчивается в пределах срока предупреждения — раз на ступень (см. Срок сертификата).

Первые два, в отличие от остальных типов, не ждут 5-минутной сводки: уходят при следующей отправке (примерно в течение минуты) и забирают с собой всё, что накопилось у получателя. Тема письма говорит всё одной строкой — «🔴 Homepage is down» / «✅ Homepage is up again».

«Сертификат истекает» приходит обычной сводкой. Владелец организации включает и выключает эти типы для проекта в Настройки → Алерты; каждый участник сам решает, получать ли их на почту и в мессенджеры, в Профиль → Уведомления. Все они также видны в истории Алертов проекта со ссылкой на монитор.

Изменение и пауза

Изменение того, что проверка запрашивает, — типа, URL, метода, заголовков, тела, gRPC-метода или сервиса, допустимых кодов, редиректов или таймаута — начинает монитор заново: он возвращается в Ожидание, а открытый инцидент закрывается без алерта о восстановлении, потому что старые результаты ничего не говорят о новой конфигурации. Изменение только названия, окружения, интервала или порогов сохраняет состояние; сниженный порог применяется со следующей проверки.

Приостановить останавливает проверки (и так же закрывает открытый инцидент); Возобновить снова запускает монитор с состояния «Ожидание». Удаление монитора удаляет и его проверки, и инциденты.

Ограничения тарифа

Тариф организации задаёт:

• сколько мониторов может быть у организации во всех её проектах (приостановленные тоже считаются);
• минимальный интервал — монитор с более частыми проверками работает с минимальным интервалом тарифа;
• сколько хранятся проверки (закрытые инциденты удаляются вместе с ними; текущий сохраняется).

Лимит мониторов и срок хранения указаны в Настройки организации → Тариф; раздел Доступность показывает, сколько мониторов у организации относительно лимита («3 из 20 мониторов организации»).

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

Частные и внутренние адреса

Чтобы мониторы нельзя было направить на собственную сеть Buglapse, URL отклоняется, если его хост — или любой адрес, в который он разрешается, на каждом редиректе — это:

• loopback (127.0.0.0/8, ::1), неопределённый адрес (0.0.0.0/8, ::);
• частная сеть (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fc00::/7);
• link-local, включая метаданные облаков (169.254.0.0/16, fe80::/10);
• shared/CGNAT (100.64.0.0/10), multicast и прочие зарезервированные (документация, бенчмарки, 240.0.0.0/4, …).

Форма скажет об этом сразу («… — частный или зарезервированный адрес»); публичный хост, который позже начнёт разрешаться в такой адрес, будет падать с ошибкой Запрещённый адрес. Соединение привязывается к проверенным адресам, так что второй ответ DNS не может подменить их внутренним.

На собственной установке, которая должна следить за внутренними сервисами, эту защиту отключает UPTIME_ALLOW_PRIVATE_NETWORKS — см. ниже.

API

Мониторы входят в API управления, в разделе проекта:

https://app.buglapse.com/api/0/projects/{organization}/{project}/uptime-monitors

Персональный токен с project:read может их читать; создание, изменение и удаление требуют project:write.

Запрос
GET uptime-monitors	Список с пагинацией. Фильтры: status (up, down, pending, paused), environment, query (название или URL).
POST uptime-monitors	Создание; тело принимает поля выше (name, type (http/grpc), url, method, headers в виде [["Name", "value"]], body, grpc_method, grpc_service, accepted_grpc_codes, timeout_seconds, interval_minutes, accepted_status_codes, follow_redirects, environment, failure_threshold, recovery_threshold, ssl_warn_days (1–90 или null), paused).
GET uptime-monitors/{id}	Один монитор со статусом, uptime_24h, открытым инцидентом и certificate (expires_at, days_left, host, subject, issuer, checked_at; null, пока https-ответа не было).
PATCH uptime-monitors/{id}	Частичное изменение; {"paused": true} приостанавливает, false возобновляет.
DELETE uptime-monitors/{id}	Удаление вместе с проверками и инцидентами.
GET uptime-monitors/{id}/checks	Журнал проверок, сначала новые. Фильтры: result, from, to.
GET uptime-monitors/{id}/incidents	Инциденты, сначала новые.
GET uptime-monitors/{id}/stats?period=24h	uptime_percent, downtime_seconds, incidents_count, avg_duration_ms, p95_duration_ms и series по отрезкам, для 24h, 7d или 30d.
POST uptime-monitors/test	Одна проверка переданной конфигурации без сохранения.

curl -X POST https://app.buglapse.com/api/0/projects/acme/my-app/uptime-monitors \
    -H "Authorization: Bearer $BUGLAPSE_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"name": "API health", "url": "https://api.example.com/health", "interval_minutes": 1}'

Отклонённый запрос отвечает 422 с полем, в котором проблема: url для запрещённого адреса, interval_minutes для интервала меньше минимального по тарифу, limit, когда достигнут лимит мониторов.

У MCP-сервера есть инструмент list-uptime-monitors, так что ИИ-ассистент может ответить на «что-нибудь лежит?» и «у чего скоро истекает сертификат?» — каждый монитор со статусом, доступностью за 24 часа, открытым инцидентом и сроком сертификата, — и get-uptime-monitor для истории одного монитора: доступность, простой и время ответа за 24 часа, 7 или 30 дней, недавние инциденты и упавшие проверки.

Своя установка

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

Переменная	По умолчанию	Что делает
UPTIME_WORKERS	2	Число процессов uptime-worker в Docker-образе. Каждый одновременно проверяет пачку до 25 мониторов, так что пары воркеров хватает надолго.
UPTIME_QUEUE_CONNECTION	redis	Соединение очереди, в которую отправляются проверки.
UPTIME_BATCH_SIZE	25	Мониторов в пачке.
UPTIME_CANARY_URL	https://www.gstatic.com/generate_204	Заведомо рабочий адрес, который запрашивается, когда проверки падают на сетевом уровне (см. Незасчитанные проверки). Укажите то, до чего ваши серверы дотягиваются всегда; пустое значение выключает защиту.
UPTIME_ALLOW_PRIVATE_NETWORKS	false	true разрешает мониторам запрашивать частные и зарезервированные адреса — для установки, которая следит за своими внутренними сервисами. Включайте, только если всем, кто может создать монитор, можно доверить доступ к этой сети.

Планировщик (schedule:work или cron-запись с schedule:run) должен работать: команда uptime:dispatch раздаёт назревшие проверки каждую минуту.

Локальная разработка за VPN

Некоторые VPN- и прокси-клиенты отвечают на DNS-запросы фиктивными адресами из зарезервированного диапазона (например, 198.18.0.0/15 или 240.0.0.0/4). Тогда любой публичный хост выглядит зарезервированным и отклоняется как Запрещённый адрес. Отключите этот режим DNS или задайте локально UPTIME_ALLOW_PRIVATE_NETWORKS=true.