Swagger Petstore - OpenAPI 3.0
GET/api/health

Liveness, database readiness, and which build is running

Doubles as a readiness probe: it pings the database and returns 503 when the DB is unreachable, rather than a cheerful 200 that hides a dead database. The only endpoint here that needs no session.

It also reports the running build (version.commit / version.branch / version.startedAt), so "is my change live?" is one unauthenticated curl instead of an SSH session — which matters for anyone who deploys but has no shell on the box.

startedAt is the PROCESS start, not the deploy. A current commit with an old startedAt means the code was updated on disk and nothing restarted — the exact failure that once made a deployed route look like a 404.

The block rides on the 503 too: a failing server is when you most want to know which build is failing. It is absent entirely when the commit cannot be resolved, never sent as null — a null would let a monitor match null against null and call it a successful deploy.

2 status codes
200The service is up and the database answered.
okbooleanoptional
servicestringoptional
dbstringoptional
`down` returns 503, not 200.
Allowed:updown
versionobjectoptional
Which build is running. **Absent** — never null — when the commit cannot be resolved, so a monitor cannot match null against null and read it as a successful deploy.
503The database did not answer.
okbooleanoptional
servicestringoptional
dbstringoptional
`down` returns 503, not 200.
Allowed:updown
versionobjectoptional
Which build is running. **Absent** — never null — when the commit cannot be resolved, so a monitor cannot match null against null and read it as a successful deploy.

Error handling

A 503 is returned: The database did not answer.