Как автоматизировать отчёты uptime через REST API?

Совет просит еженедельный слайд с uptime %, а вендор отдаёт только CSV из дашборда, который вы забываете открыть. REST API — машиночитаемое меню: скрипт спрашивает «что было доступно на прошлой неделе?» и получает JSON вместо скриншотов. Здесь — какие поля API обязан отдавать для автоматизации отчётов, сравнение UptimeRobot, Better Stack, Checkly, StatusCake и StillOnline на pull-стиле reporting и sample workflow без пяти вкладок.

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

Для автоматизации отчётов нужны pull-endpoints: status, uptime %, время последней пробы, инциденты. UptimeRobot v3 отдаёт logs и response times на всех тарифах — на Free около 10 запросов в минуту. Better Stack добавляет SLA-сводки и incident log drains. Checkly — aggregated reporting и CLI stats для dev-команд. StatusCake v1 тянет history, но без публичного JSON статуса. StillOnline даёт keyless public JSON с uptime_7d плюс private checks и MCP на Pro ($9/мес). Частота опроса — раз в период отчёта, не каждую минуту.

Мониторинг доступности пингует URL по расписанию. REST API отдаёт сохранённые результаты проб — как официант приносит распечатку статуса вашему скрипту. Автоматизация отчётов — cron тянет JSON и постит сводку в Slack, почту или таблицу.

Хабы: REST API uptime и статуса · MCP для AI-агентов · Справочник API StillOnline.

Выберите: какие поля API нужны для отчёта

Перед сравнением вендоров зафиксируйте, на что должен отвечать отчёт. Инвесторам нужен uptime %. Инженерам — время последней пробы и открытые инциденты. Клиентам — зелёный/красный badge. Pull API возвращает сохранённые результаты фоновых worker'ов — не заменяет сами проверки.

Делайте: минимум overall status, last result по каждому URL, timestamp последней пробы, uptime за окно (7d или 30d). Не делайте: не думайте, что каждый GET запускает новый ping — большинство API отдают stored results.

Минимальный набор: overall status → status по URL → uptime % → open incident (если есть) → опционально latency.

  1. Список стейкхолдеров и полей для каждой группы (exec summary vs on-call).
  2. Pull (cron вызывает API) vs push (webhooks вендора).
  3. История или только snapshot — возможно, нужны daily snapshots у себя.
  4. Rate limits тарифа до hourly polls.
  5. Коммерческое использование и доступ к API (UptimeRobot API на Free; private StillOnline — Pro+).

Сравните: UptimeRobot, Better Stack, Checkly, StatusCake, StillOnline

Пятёрка в каждом indie-shortlist, когда важна автоматизация отчётов. Pull endpoints — cron читает сохранённые результаты. Pre-built aggregates экономят rollup из сырых logs.

ИнструментPull для reportingГотовые агрегатыPush / webhooksAPI на entry tierОговорка
UptimeRobotGET monitors + logs, response times (v3)Uptime ratio в ответе monitorAlert webhooks; rollup свойДа, включая Free (10 req/min)DIY pipeline; путаница v2/v3
Better StackIncidents v3; monitor SLA v2 с date rangeAvailability %, downtime secondsIncident log drain (audit JSON)API с аккаунтом; verify planv2/v3 mix; add-on pricing
ChecklyCheck results v2; reporting v1 aggregateCLI checkly checks statsAlert channels; CLI для агентовAPI на paid (verify tier)Raw 30 дней; 5 req/10s
StatusCakeGET uptime list, history, periods, alertsUptime % на list endpointАлерты; нет public status JSONv1 Bearer (paid tiers)Нет public reporting endpoints в v1
StillOnlinePublic status JSON; private checks; MCPuptime_7d per componentOwner alerts в UI, не webhook drainPublic JSON на Free; private Pro+ ($9)Нет /reporting aggregate

Делайте: HTTP ping — UptimeRobot, StatusCake; SLA webhooks — Better Stack reporting API; synthetic — Checkly; status slug + MCP — StillOnline Pro. Не делайте: не покупайте Checkly ради одного homepage ping.

Вердикт: UptimeRobot — budget DIY reporting. Better Stack — webhook audit + SLA pulls. Checkly — checks-as-code команды. StatusCake — private history без public JSON. StillOnline Pro — один project = один status slug, public JSON для клиентов + MCP для weekly agent summaries.

Разделите: public status JSON vs private API key

Public status JSON — без пароля, для клиентских виджетов и release checklists. StillOnline public GET — около 60 req/min per IP, кэш ~60 секунд. Private API key (Bearer) — owner-поля вроде last_probed_at и pause state.

Делайте: public JSON наружу, ключи только в server env. Не делайте: public GET по private slug StillOnline (404). У StatusCake v1 нет keyless JSON; у UptimeRobot read-only keys безопаснее для reporting-only скриптов.

Полная матрица endpoints — в гайде REST API.

Подключите: MCP для AI-агентов (StillOnline Pro)

MCP (Model Context Protocol) даёт агенту Cursor или Claude вызывать StillOnline tools (status.get, checks.list) вместо вставки JSON в чат. stillonline-mcp на Pro ($9/мес), зеркалит справочник API. Checkly — похожий угол через CLI stats для checks-as-code.

Делайте: MCP для черновиков сводок в чате; REST cron для Monday Slack posts. Не делайте: не вставляйте API keys в чат. Настройка: MCP для AI-агентов.

Соберите: sample reporting workflow

Workflow: define fields → pick endpoint → schedule pull → normalize JSON → Slack/Sheets → archive snapshots.

  1. Скопируйте минимальный набор полей из раздела 1 в one-page spec.
  2. Одна строка endpoint на prod URL (slug для public, project id для private).
  3. Daily или weekly pulls под rate limits вендора.
  4. Храните date, status, uptime window, open incident flag.
  5. Пост в Slack; ссылка на public status page для клиентов.
  6. Archive 90+ дней, если контракты ссылаются на uptime thresholds.

На StillOnline Pro создайте ключ в дашборде, private checks для owner metrics, public JSON для client sections. Тарифы — перед масштабированием.

Что дальше

  1. Прогоните field checklist по вашему вендору.
  2. Прототип одного public JSON pull.
  3. Апгрейд для private keys, если нужны owner metrics.
  4. MCP для Cursor-команды.
  5. Задокументируйте poll limits в runbook.

StillOnline Pro — один status slug на project. Сравните прозрачные цены перед годовой оплатой. Детали endpoints — в хабе REST API uptime.

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

FAQ

Какие поля должен отдавать uptime API для автоматических отчётов?

Overall status, last result по check, время последней пробы, uptime за фиксированное окно и open incidents. Latency — только если SLA требует; иначе храните daily snapshots сами. StillOnline public JSON включает uptime_7d per component — см. гайд REST API.

Можно ли через UptimeRobot API тянуть monitor logs для weekly reports?

Да, v3 GET monitors с logs и response_times. Weekly rollup — в своём хранилище. Free tier — около 10 req/min по докам UptimeRobot v3.

Экспортирует ли Better Stack API SLA и incidents для отчётов?

Да — monitor SLA с date range и incidents v3 filters. Incident log drains — audit events для compliance-style reports по докам Better Stack reporting.

Подходит ли Checkly для автоматизации uptime reporting?

Лучше для synthetic API/browser checks. Reporting aggregate или CLI stats; архивируйте snapshots — raw results ~30 дней по Checkly check results API.

Есть ли у StatusCake public status JSON как у StillOnline?

Нет public reporting endpoints в v1. Все pulls — Bearer token; автоматизируйте private reports из uptime history по докам StatusCake API.

Входит ли REST API в StillOnline Free для reporting?

Private API на Free нет. Public status JSON без ключа, если страница public. Pro открывает private checks и MCP — гайд REST API.

REST или MCP для reporting из Cursor?

REST для cron и CI; MCP — когда агент черновит сводку из checks.list после инцидента. Те же данные StillOnline на Pro+. Настройка — гайд MCP.

Как часто опрашивать uptime API для автоматических отчётов?

Раз за период отчёта (daily/weekly), не каждый check interval. Учитывайте rate limits и cache — StillOnline public JSON кэшируется ~60 секунд, UptimeRobot Free — ~10 req/min.