System

Readiness probe

What a deploy gate should look at — reports whether this process can actually serve traffic.

GET/v1/health/readyRequires X-API-Key

Unlike GET /v1/health, this one checks its dependencies: the database connection, the cache and, when encryption is configured, that every active key purpose the registry expects is actually loaded.Answers 200 with status: "ready" when everything it checked is fine, and 503 with status: "not ready" otherwise — so an orchestrator takes the replica out of rotation and a deploy gate fails, rather than both concluding all is well. Each dependency also gets its own line in checks, so a 503 tells you which one: up / down / not configured for the database and cache, loaded / incomplete / unknown for encryption keys. not configured is not a failure — a deployment can legitimately run without a dependency wired up, with whatever features need it switched off — only down, incomplete and unknown fail the probe.Like GET /v1/health, this one does not require an API key — it sits in the public group alongside it, behind only an IP rate limit, so an orchestrator can call it before any credential exists.

Request example

curl --request GET \
  --url https://api.norba.io/v1/health/ready \
  --header "X-API-Key: $NORBA_KEY"

Response example

{
  "status": "ready",
  "checks": {
    "database": "up",
    "cache": "up",
    "encryptionKeys": "loaded"
  }
}

Authorization

X-API-KeystringRequired

Opaque API key issued from the Norba dashboard. Sent on every request as the X-API-Key HTTP header. Missing or invalid keys are rejected with 401 Unauthorized.

Response fields

statusstringRequired

ready or not ready.

checksobjectRequired

One entry per dependency checked: database, cache, and encryptionKeys when encryption is configured.