Health

Status: 🟢 Estável (liveness + readiness probes) Code: backend/app/modules/health Última revisão deste doc: 2026-05-13 por Felipe + Claude

1. Identidade

O que faz (uma frase)

Liveness + readiness probes pra Uptime Kuma, K8s/Coolify orchestrator e status page pública (status.mandir.com.br) — sem autenticação, sem estado, queries imediatas.

Por que existe

Monitoring + load balancer health checks precisam endpoint dedicado público sem auth.

2. Cases de uso

Uptime Kuma chama /api/health/status a cada 60s → status page pública.
K8s/Coolify chama /api/health/ready → tira pod do load balancer se DB down.
Load balancer interno chama /api/health/ok → liveness puro.

3. Arquitetura

routes.py — 4 endpoints.

Tabelas

4. API / Endpoints (4)

Método	Rota	Auth	O que faz
GET	`/api/health/ok`	Público	Heartbeat puro (sem DB call). 200 `{status: "Mandir Suite OK"}`
GET	`/api/health/db`	Público	DB connectivity (`SELECT current_database, current_user`). Resolve tenant via middleware. 200 ou 503
GET	`/api/health/status`	Público	`{status, service, env, build (git SHA[:12]), timestamp}` — pra status page
GET	`/api/health/ready`	Público	Force `SELECT 1`. 200 `ready` ou 503 — pra K8s/Coolify orchestrator

5. Limitações e débitos técnicos

#	Item
1	`/db` tenant-aware
2	`/status` nunca expor PII
3	Sem circuit breaker

6. Histórico

Em prod desde Suite v2.