The API exposes a health endpoint at /health (and the identical alias /api/health). It’s what the deployment pipeline smoke-probes after every release and what the home page’s API status light reads.
What it returns
{
"status": "ok",
"service": "crm-api",
"version": "0.0.1",
"region": "AU",
"postgres": "ok",
"timestamp": "2026-05-29T03:14:00.000Z"
}The response is always HTTP 200 — even if Postgres is unreachable. The actual subsystem state lives in the body’s postgres field, which reads "ok" on a clean pool ping and "fail: …" with the driver error otherwise. That split lets uptime pollers and humans distinguish process unreachable (non-200) from process up, database down (200 with postgres: "fail: …").
How to hit it
curl https://crm.infiveminutes.com/health curl http://localhost:4009/health # local dev
What it does NOT check
- The shared
llama-serverat:8090. Local LLM availability is checked per-agent at run time, not at process start. - Meta’s WhatsApp Business API.
- The Platform’s public-key endpoint.
Both/healthand/api/healthare unauthenticated by design. They stay open even whenCRM_DEV_FALLBACK=falseand every other route requires a Bearer JWT — the deploy probe and the public landing page both need them.