Мониторинг API для API-first SaaS
Quick answer
API-first SaaS зависит от доступности endpoint. StillOnline делает GET по расписанию на /health, /ready или публичные маршруты с внешних проб, обновляет status page и отдаёт публичный status JSON на api.stillonline.tech/v1/public/status/{slug} — без API-ключа для чтения.
Проблема
- Интеграторы и AI-агенты бьют в API, а не в лендинг.
- «Зелёный» дашборд внутри VPC не доказывает доступность для клиентов.
- Нужен машиночитаемый статус, не только HTML.
Как помогает StillOnline
- Проверки на
https://api.yoursaas.com/health(или аналог). - Публичный status JSON для скриптов, партнёров и агентов.
- Приватный REST API и MCP на Pro/Ultimate — управление из Cursor или CI.
- SSL-проверки в той же квоте URL.
Быстрый старт
- Поднимите health route с HTTP 200 (гайд).
- Зарегистрируйте URL в StillOnline.
- Укажите
GET /v1/public/status/{slug}в доке API. - По желанию — MCP после деплоя (возможность MCP).
Когда выбирать StillOnline
- Продукт в основном API с тонким веб-UI.
- Нужны status JSON и человекочитаемая страница без своей разработки обоих.
- AI-агенты в пайплайне должны читать production health.
Когда не выбирать
- Нужны синтетические сценарии, проверка полей JSON или кастомные заголовки на каждой пробе (сверяйте с текущим продуктом).
- Глубокая аналитика API по всем маршрутам — APM-инструменты.
- StillOnline проверяет HTTP-доступность, не бизнес-логику каждого endpoint.
FAQ
Какой URL мониторить API-first продукту?
Обычно /health или /ready без авторизации. Не используйте только admin-пути.
Могут ли партнёры опрашивать статус без ключа?
Да — публичный status JSON по slug проекта.
Проверяет ли StillOnline тело JSON?
Сейчас фокус на HTTP-коде и доступности. Для JSON-паттернов — гайды в блоге и changelog.