Дизайн health URL: /health и /ready для SaaS
Внешние мониторы (включая StillOnline) видят только HTTP-ответ на выбранный URL. Хороший дизайн health снижает ложные тревоги при деплое и ложное «всё ок», когда БД уже недоступна.
После деплоя маршрута зарегистрируйте его в StillOnline, дайте страницу статуса клиентам, когда нужна прозрачность, и включите алерты владельца через бота StillOnline в Telegram (гайд). Выбор конечной точки — это и продуктовое решение, и инженерное.
Краткий ответ
Для большинства indie SaaS достаточно лёгкого GET /health с 200 быстрее двух секунд, без auth и секретов. Зарегистрируйте prod HTTPS в StillOnline, делитесь размещённой ссылкой на страницу статуса по запросу или при сбое и включите алерты владельца через бота StillOnline или email в настройках.
/health и /ready
В Kubernetes различают liveness и readiness. Uptime-инструменту важен код ответа; имя маршрута задаёт, что «up» значит для клиентов.
| Маршрут | Смысл | Когда мониторить |
|---|---|---|
/health (liveness) | Процесс жив | «Не совсем мёртв» |
/ready (readiness) | Готов принимать трафик (БД, миграции) | Имеет смысл помечать down при деплое |
По умолчанию для indie: лёгкий /health без пинга БД. /ready — если клиентам нужно видеть down на время выката.
Имена путей
Важнее единообразие, чем мода. Один канонический путь — в README, runbook и StillOnline.
GET /health— монолит.GET /api/health— API с префиксом (API-only SaaS).- Фиксируйте полный HTTPS URL — смена пути ломает закладки.
Тело ответа
Тело должно быть маленьким и безопасным для поддержки. StillOnline пишет код и latency; JSON читают люди при разборе.
{ "status": "ok", "version": "1.2.3" }
- 200 — здоров, 503 (или стабильный 500) — нет.
- Ответ быстрее 2 с.
- Без секретов и PII.
БД и Redis
Глубокие проверки меняют баланс честности и шума. Глубина должна совпадать с тем, что «down» значит на публичной странице статуса.
| Стратегия | Компромисс |
|---|---|
Лёгкий /health без БД | Проверка зелёная при мёртвой БД |
Ping в /ready | Честно, но шумно при деплое |
| Вторая глубокая проверка | Два URL на Pro |
Auth и сеть
Проверки идут с публичного интернета, не из вашего VPC.
- Health без API-ключей.
- Не
localhost. - Редирект-петли на
/— бейте в/health; антибот может дать PROBE_LIMITED — гайд по странице статуса.
Подключение к StillOnline
Когда curl снаружи даёт 200, добавьте тот же URL в StillOnline.
- Задеплоить маршрут в prod.
curlне из вашей сети.- Приложение → проверка → зелёная страница.
- Настройки → Подключить Telegram → бот → алерты.
Пошагово: быстрый старт health.
Связанные материалы
FAQ
StillOnline проверяет health через GET или HEAD?
По умолчанию StillOnline шлёт GET. Реализуйте стабильный GET на health и укажите тот же URL в README и в кабинете StillOnline. Пошагово: быстрый старт health URL.
В StillOnline нужно добавлять только HTTPS URL?
Да — тот же TLS-адрес, что видят клиенты в prod; редиректы с http:// часто дают ложные срабатывания. После зелёных проб делитесь stillonline.tech/ru/s/... в документации или при подключении клиентов: публичная страница статуса.
Можно ли в StillOnline мониторить health с ответом 204?
Практичнее 200 с небольшим JSON — проще отладка через curl. Без PII и секретов — быстрый старт health URL.
Сколько health URL помещается на StillOnline Free?
На Free — один проект и один URL; выберите критичный путь (часто API /health). Больше проверок — тарифы и API-only SaaS.
Должна ли health-проверка StillOnline пинговать БД?
Только если «up» = «БД доступна». Иначе лёгкий /health — меньше ложных DOWN на деплое. На Pro — больше URL для глубокой проверки.
Может ли StillOnline проверять health за API-ключами?
Нет — внешней проверке нужен публичный health без ключей. Ключи — на бизнес-маршрутах; алерты — Telegram, бот StillOnline.