Health check URL для SaaS — быстрый старт

До тяжёлого observability сделайте одну скучную вещь: стабильный URL, который отдаёт HTTP 200, когда приложение и критичные зависимости живы. Внешний мониторинг — включая StillOnline — видит только этот URL, не ваши логи.

Гайд без привязки к платформе. Для Vercel и Railway — отдельные статьи: Vercel, Railway.

Шаг 1 — выберите путь

• GET /health — liveness (процесс поднят).
• GET /api/health — API за gateway.
• GET /ready — readiness с БД (осторожно при деплоях).

Один канонический путь в доках и мониторинге.

Шаг 2 — быстрый handler

• Ответ < 2 с.
• JSON { "status": "ok" } или текст ok.
• Пинг БД — только если готовы к downtime при кратком blip БД.

Без секретов и stack trace в теле.

Шаг 3 — curl извне

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

Нужен 200. При 301 — поправьте редиректы. При 401 — health случайно закрыт авторизацией.

Шаг 4 — StillOnline

1. Начать бесплатно.
2. Новый проект → имя + slug status page.
3. Проверка → полный HTTPS URL, GET, 200, интервал 5 мин (Free).
4. Откройте status page — зелёный после 2–3 циклов.

Free: 1 проект, 1 URL, история 24 ч. Больше — Тарифы, Pro $9/мес.

Шаг 5 — люди и агенты

• Ссылка на status page в футере и support.
• Email-подписка на странице статуса.
• На Pro — stillonline-mcp в Cursor (статья про MCP).

Чего это не решает

• SSL — отдельные инструменты или регистратор.
• Только воркеры упали — shallow /health может врать; нужны метрики глубже.
• OpenClaw локально — сначала tunnel (гайд).

Выбор инструмента: shortlist 2026.

FAQ

Корень сайта или /api/health?

Мониторьте то, чем пользуются клиенты. API-first — хост API.

HEAD вместо GET?

Лучше GET, если не проверили HEAD на хостинге.

Staging и production?

На Free один URL — отдельные аккаунты, Pro на 10 URL или только production снаружи.

Чем это не Analytics Vercel?

Analytics — про трафик; health URL — про доступность и status page.