Health check пула соединений с БД для API-only SaaS

Под нагрузкой приложение отдаёт 500 не потому, что Postgres мёртв — исчерпан connection pool. Внешний монитор, бьющий в /, узнает позже клиентов.

StillOnline фиксирует HTTP-код и задержку на зарегистрированном URL. /health или /ready, который берёт соединение и отдаёт 503 при насыщении pool, превращает давление в DOWN на странице статуса.

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

GET /ready (или /health, если готовы к blip при деплое) с SELECT 1 или acquire() и коротким timeout — 503, если соединение не выдали за < 500 мс. URL в StillOnline; пять минут на Free, две неудачи подряд → DOWN. Исчерпание pool и падение хоста БД различайте в тексте инцидента; код может быть одинаковым 503. Шаблон JSON ниже; паттерны API — API-only.

Pool vs простой БД

Пул соединений PostgreSQL конечен — health должен отваливаться быстро.

Шаблон JSON

{
  "status": "ok",
  "checks": {
    "database": "ok"
  }
}

При сбое:

{
  "status": "error",
  "checks": {
    "database": "pool_timeout"
  }
}

503, без строк подключения — дизайн health.

curl -sS -w "\n%{http_code}\n" https://api.yourproduct.com/ready

StillOnline

1. Приложение → HTTP → /ready → 200.
2. Инцидент на API — публичная страница.
3. Pro — /health и /ready отдельно; Free — один URL.

Ложные алерты.

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

• Дизайн health endpoint
• API-only SaaS
• Мониторинг Supabase
• Neon и PlanetScale

FAQ

Ночные blip pool?

Два fail при 5 мин ≈ 10 мин красного. Сначала pool и timeout.

StillOnline читает поле database в JSON?

Нет — только код HTTP. Маппите pool → 503 в handler.

Хватит status managed БД?

status.supabase.com — платформа, не ваш pool; мониторьте свой /ready.