Статус живости сервисов через REST API StillOnline

Кабинет удобен людям. Скрипты, CI, внутренние боты и runbook нуждаются в стабильном HTTP-контракте: зелёный ли API по последней проверке и есть ли открытый инцидент.

REST API v1 StillOnline даёт два read-пути для живости / uptime:

1. Публичный — GET /v1/public/status/{slug} — без ключа, JSON для страницы статуса.
2. Приватный — GET /v1/projects/{id}/checks — last_status, last_probed_at, пауза.

База: https://api.stillonline.tech/v1. Справочник: /ru/docs/api. Для агентов в Cursor/Windsurf — настройка MCP.

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

REST API v1 StillOnline для скриптов: публичный GET /v1/public/status/{slug} без ключа; приватный GET /v1/projects/{id}/checks с Bearer sk_live_… (Pro/Ultimate). GET возвращает сохранённые результаты проб — workers StillOnline ходят на ваш health URL по расписанию. Алерты владельца о down/восстановление — в UI (Алерты в Telegram, Алерты в Slack), не через эти GET.

Какой endpoint выбрать

StillOnline намеренно разделяет клиентский read и владельческий: публичный JSON без секрета; списки checks — с ключом и тарифом Pro. Выберите строку по тому, кто будет читать ответ.

Приватные методы — Pro ($9/мес) или Ultimate, ключ в настройках API. На Free нет API — только UI или публичный JSON при public visibility.

Публичный статус (без ключа)

Тот же JSON, что на странице статуса StillOnline.

curl -sS "https://api.stillonline.tech/v1/public/status/my-saas"

Подставьте slug страницы статуса или id проекта (cuid из URL кабинета).

Пример ответа (200):

{
  "slug": "my-saas",
  "status": "operational",
  "updated_at": "2026-05-29T10:00:00.000Z",
  "components": [
    {
      "name": "API",
      "url": "https://api.example.com/health",
      "status": "operational",
      "uptime_7d": 99.9,
      "ssl_valid_until": null
    }
  ],
  "active_incident": null
}

Статусы: operational, degraded, down, unknown (общий и по компонентам).

Лимит: 60 запросов/мин с IP → 429 и Retry-After. Кэш ответа ~60 с.

404 — нет slug или visibility private.

Подходит для:

• curl в чеклисте релиза
• простого скрипта uptime
• интеграций без секретов

Сначала health URL: быстрый старт.

Приватный: checks и last_status

Для ваших проектов — Bearer:

curl -sS \
  -H "Authorization: Bearer sk_live_..." \
  "https://api.stillonline.tech/v1/projects/PROJECT_ID/checks"

PROJECT_ID через:

curl -sS \
  -H "Authorization: Bearer sk_live_..." \
  "https://api.stillonline.tech/v1/projects"

Пример check:

{
  "id": "clx…",
  "project_id": "clx…",
  "name": "API",
  "url": "https://api.example.com/health",
  "method": "GET",
  "interval_seconds": 300,
  "enabled": true,
  "last_status": "OPERATIONAL",
  "last_probed_at": "2026-05-29T09:57:10.362Z"
}

last_status — результат последней внешней HTTP-проверки StillOnline к вашему URL.

Значения: OPERATIONAL, DOWN, DEGRADED, UNKNOWN (внутренний enum; в публичном JSON — lowercase).

Пауза проверки

PATCH /checks/{id} с {"enabled": false} — пауза одного URL. После паузы:

• проверки останавливаются
• last_status может остаться OPERATIONAL — последний результат до паузы
• в кабинете бейдж «Пауза»

Возобновление: {"enabled": true}. Пауза всего проекта — кнопки в кабинете.

Лимиты и ошибки

В скриптах на 429 делайте паузу по Retry-After. Корзины ниже — отдельно на IP (публичное) и на API-ключ (приватное); частый опрос публичного статуса не съедает write-квоту.

При превышении: 429, RATE_LIMIT, Retry-After.

Ещё коды:

• 401 — нет или неверный Bearer
• 404 — неверный id или мягко удалённый проект
• 403 — лимит плана или Free без API

Пример: упасть в CI, если production down

#!/usr/bin/env bash
set -euo pipefail
SLUG="my-saas"
json=$(curl -sf "https://api.stillonline.tech/v1/public/status/${SLUG}")
status=$(echo "$json" | jq -r '.status')
if [[ "$status" != "operational" ]]; then
  echo "StillOnline: $status"
  exit 1
fi
echo "OK: $status"

Для логики владельца (игнор на паузе) — приватный список checks и поля enabled + last_status.

Write (кратко)

Чтение статуса — только GET. Чтобы создавать мониторинг из кода:

• POST /projects — проект + первая проверка
• POST /projects/{id}/checks — добавить URL
• POST https://api.stillonline.tech/v1/status-pages/{id}/incidents — открыть инцидент (active_incident в публичном JSON)

Каталог: /ru/docs/api. MCP — тот же API: /ru/docs/mcp.

Windows PowerShell

Осторожно с кавычками в curl -d. Для кириллицы в JSON — UTF-8 и Content-Type: application/json; charset=utf-8. Подробнее на странице документации, блок Windows PowerShell.

Алерты владельца (не через API)

REST API читает результаты проб и JSON статуса. Уведомления людям о down, восстановлении и 24 ч — через email, Telegram или Slack в кабинете (настройки). Гайды: Алерты в Telegram · Алерты в Slack. На Free — один канал владельца; на Pro / Ultimate — все три.

FAQ

Когда в StillOnline использовать публичный или приватный REST endpoint?

GET /public/status/{slug} — для виджетов, CI и интеграций без секретов; то же, что публичная страница статуса. GET /projects/{id}/checks с Bearer — для last_probed_at, паузы и last_status по URL (только Pro/Ultimate).

REST API StillOnline пингует мой сервер при каждом GET?

Нет. GET читает сохранённые результаты проб workers StillOnline по интервалу (на Free — 5 мин). Сначала добавьте health URL.

Можно ли получить приватную страницу статуса StillOnline без API-ключа?

Нет. GET /public/status/{slug} даёт 404 при visibility private. Нужен приватный API с sk_live_… из настроек API или кабинет StillOnline.

Есть ли REST API StillOnline на тарифе Free?

На Free нет API-ключа — один URL и 24 ч истории в UI. Публичный JSON страницы статуса работает без ключа, если visibility public. Pro — приватное чтение, write и MCP.

Чем REST StillOnline отличается от stillonline-mcp?

Одна модель данных. REST — скрипты, CI, бэкенд; MCP — агенты в Cursor/Claude. Pro/Ultimate нужны для приватного API; публичный status GET — без ключа.