API Reference
Health check
GET /api/health returns the running status of the service and its components, for monitoring and liveness probing.
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://citeark.com/api/healthResponse
{
"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.