← Блог

Что мониторить в API-only SaaS

Если клиенты ходят через REST, вебхуки или API keys, «главная открывается» — плохой сигнал. Uptime — это хост API и маршрут health, плюс публичная страница статуса с историей сбоев.

StillOnline бьёт по публичному HTTPS и собирает страницу автоматически. Владельцу — email, Telegram (бот StillOnline) или Slack, чтобы узнать о проблеме с интернета раньше, чем интеграторы откроют тикеты.

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

Для API-only SaaS мониторьте один публичный GET /health или /api/health с 200, когда продукт реально доступен — не один лендинг. Зарегистрируйте полный HTTPS в StillOnline, добавьте ссылку на страницу статуса StillOnline в документацию для разработчиков и включите алерты через бота StillOnline. На Free — один проект и один URL.

Один канонический health URL

Один URL в README, StillOnline и продажах — меньше споров при инциденте.

ПутьКогда
GET /healthОдин сервис, liveness
GET /api/healthAPI за префиксом /api
GET /readyГотовы к ложным DOWN при деплое/БД

Зафиксируйте путь в README и в StillOnline. Дизайн: дизайн health URL · быстрый старт.

curl -sS -o /dev/null -w "%{http_code}\n" https://api.yourproduct.com/health

С любой машины вне вашей сети — ожидайте 200.

Не ставьте проверку сюда

Неверная цель даёт зелёную панель и злых интеграторов.

  • Только маркетинговый лендинг — если он не блокирует ваш сценарий «продукт недоступен».
  • Статус OAuth-провайдера — дайте ссылку на их страницу статуса.
  • localhost / закрытый VPC — снаружи не видно (агенты / OpenClaw).

Страница статуса для интеграторов

Интеграторы кладут ссылку рядом с OpenAPI.

  1. Проект с именем продукта.
  2. Проверка health (Free: один URL, интервал 5 мин).
  3. https://stillonline.tech/ru/s/{project-id} в доке для разработчиков или API reference.
  4. JSON: REST: статус.

На странице — подписка через Google для email при смене статуса.

Алерты для дежурного фаундера

Внешние проверки не разбудят вас без настроенных каналов владельца.

  1. НастройкиПодключить Telegramбот StillOnlineStart.
  2. Включить алерты в Telegram (или email / Slack). Free: один канал; Pro / Ultimate: все три. Гайд Telegram.

Статус down — после двух неудачных проверок подряд; в Telegram сообщения повторяются на каждом интервале, пока сервис недоступен.

Несколько окружений

На Free приходится выбирать — обычно это правильно на старте.

Free — один проект, один URL. Staging и prod — два проекта на Pro или только prod.

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

FAQ

Должна ли health-проверка StillOnline пинговать БД в API-only SaaS?

Только если «API up» = «БД доступна». Иначе лёгкий /health — меньше ложных срабатываний на деплое: дизайн health URL. На Pro — больше URL для глубокой проверки.

Какой URL мониторить в StillOnline при проблемах с вебхуками?

Ваш URL точки приёма, который принимает входящие вебхуки — не callback каждого клиента. На Free — один критичный путь: тарифы.

Как настроить StillOnline для GraphQL API?

GET /health на том же хосте, что GraphQL; зарегистрируйте HTTPS и дайте /s/... в документации API. Быстрый старт health · публичная страница статуса.

Может ли StillOnline проверять health за API-ключами?

Нет — внешней проверке нужен публичный health без ключей. Ключи — на бизнес-маршрутах; алерты — Telegram, бот StillOnline.

Куда положить ссылку на страницу статуса StillOnline для API-клиентов?

В документации, README, API reference или при подключении клиентов — по запросу или при сбое. Отдельный домен для страницы статуса в StillOnline не предусмотрен — см. публичную страницу статуса.

Сколько проектов StillOnline нужно для staging и production API?

На Free один URL — мониторьте prod. На Pro — отдельные проекты или больше проверок для staging — тарифы · публичная vs приватная.