Skip to main content
curl -s https://api.usedatabrain.com/health/live

{
  "status": "live"
}
GET
/
health
/
ready
curl -s https://api.usedatabrain.com/health/live

{
  "status": "live"
}
Health check endpoints for monitoring and orchestrator probes. GET /health/live confirms the process is running. GET /health/ready verifies dependencies (Hasura, Keycloak, Postgres) are reachable. Both work for self-hosted and cloud deployments.
Base URL: Health is mounted at /health. If your deployment uses a path prefix (e.g. /api), use /api/health/live and /api/health/ready. For self-hosted, replace the host with your instance URL.

​
Endpoint (Cloud)

GET https://api.usedatabrain.com/health/live
GET https://api.usedatabrain.com/health/ready

​
Self-hosted Databrain Endpoint

GET <SELF_HOSTED_URL>/health/live
GET <SELF_HOSTED_URL>/health/ready

​
Guide: How to check health

  1. Liveness — Call GET /health/live. Expect 200 and {"status":"live"}. Use for liveness probes.
  2. Readiness — Call GET /health/ready. Expect 200 and {"status":"ready","checks":{...}} when all dependencies are up. Inspect checks for per-service status.
  3. If any check is DOWN or UNKNOWN, the response is 503 and status is not_ready.

​
Authentication

None. Health endpoints do not require authentication.

​
Headers

None required.

​
Query Parameters

None.

​
Response

​
GET /health/live (200 OK)

​
status
string
Always "live" when the server responds. Indicates the process is running.

​
GET /health/ready – Success (200 OK)

​
status
string
"ready" when all configured dependency checks pass.
​
checks
object
Map of service names to their health result. Keys present depend on configuration.
​
checks.hasura
object
Always present. Hasura GraphQL engine health. Uses {HASURA_ENDPOINT}/healthz. No change required on Hasura; backend uses the existing endpoint.
​
checks.hasura.status
string
"UP" when Hasura is reachable, "DOWN" when unreachable, "UNKNOWN" when HASURA_ENDPOINT is not configured.
​
checks.hasura.statusCode
number
HTTP status from {HASURA_ENDPOINT}/healthz. Present when a response was received. Absent on network/fetch errors.
​
checks.hasura.error
string
Present when status is "DOWN" or "UNKNOWN". Error message or configuration hint (e.g. "HASURA_ENDPOINT not configured").
​
checks.keycloak
object
Present only when KEYCLOAK_SERVER_URL is set. Keycloak health via {KEYCLOAK_SERVER_URL}/health/live.
​
checks.keycloak.status
string
"UP" or "DOWN".
​
checks.keycloak.statusCode
number
HTTP status from Keycloak. Present when a response was received.
​
checks.keycloak.error
string
Present when status is "DOWN". Error message.
​
checks.postgres
object
Present only when HASURA_ENDPOINT is set. Postgres reachability via Hasura strict health ({HASURA_ENDPOINT}/healthz?strict=true).
​
checks.postgres.status
string
"UP" or "DOWN".
​
checks.postgres.statusCode
number
HTTP status from Hasura strict health. Present when a response was received.
​
checks.postgres.error
string
Present when status is "DOWN". Error message.

​
GET /health/ready – Failure (503 Service Unavailable)

​
status
string
"not_ready" when one or more checks failed.
​
checks
object
Same structure as success. At least one entry has status: "DOWN" or "UNKNOWN".

​
Services summary

ServiceConfigCheck URLIn checks when
HasuraHASURA_ENDPOINT{endpoint}/healthzAlways
KeycloakKEYCLOAK_SERVER_URL{url}/health/liveWhen config is set
Postgres(via HASURA_ENDPOINT){HASURA_ENDPOINT}/healthz?strict=trueWhen Hasura config is set

​
Examples

​
HTTP Status Code Summary

Status CodeEndpointDescription
200GET /health/liveOK – Process is running; {"status":"live"}
200GET /health/readyOK – All configured checks pass; {"status":"ready","checks":{...}}
503GET /health/readyService Unavailable – One or more checks failed; {"status":"not_ready","checks":{...}}

​
Notes

  • Each dependency check uses a 3 second timeout.
  • statusCode is omitted when the check fails due to network/connection errors (e.g. ECONNREFUSED).
  • For Kubernetes: use GET /health/live for liveness and GET /health/ready for readiness.
  • Graceful shutdown: On SIGTERM or SIGINT, the server stops accepting new connections and waits for in-flight requests to complete. If shutdown is not complete within 30 seconds, the process exits forcefully. Set terminationGracePeriodSeconds to at least 35 when using Kubernetes.