Health check

GET /api/health

Returns the service's running status, for monitoring and liveness probing. The endpoint is public, takes no parameters, and always responds with cache-control: no-store.

Returns 200 when all components are healthy; returns 503 when any component is failing, with the specific degraded components marked in components.

curl https://hypoark.com/api/health

Response

{
  "status": "ok",
  "service": "citeark-web",
  "revision": "citeark-00042-abc",
  "components": {
    "database": { "status": "ok", "latencyMs": 12 },
    "objectStorage": { "status": "ok", "latencyMs": 30 },
    "authentication": { "status": "ok" },
    "configuration": { "status": "ok" },
    "signing": { "status": "ok" }
  },
  "checkedAt": "2026-01-01T00:00:00.000Z"
}

Field	Description
status	Overall status: ok or degraded (corresponding to HTTP 200 / 503)
service	Always citeark-web
revision	Currently deployed revision
components	Health of each component; see the table below
checkedAt	ISO time of this check

components contains five components, each with a status (ok or failed):

Component	Description
database	PostgreSQL connectivity and database migration version check, with latencyMs; includes detail on failure
objectStorage	R2 object storage connectivity check, with latencyMs; includes detail on failure
authentication	Whether authentication-related environment variables (sign-in, email, etc.) are all present
configuration	Whether the production configuration is complete
signing	Whether the artifact signing key (KMS or private key) is configured

Notes

This endpoint only checks dependency connectivity and configuration; it does not mean all business functionality is available. A 503 response is also a valid health-check signal — monitors should alert on both the status code and the status field.