Health Check

Unauthenticated liveness and readiness endpoints for monitoring Signa from your side

GET /v1/health

cURL

# Liveness alias under /v1
curl https://api.signa.so/v1/health
# -> {"status":"ok"}

# Readiness: what your monitoring agent should hit every 60s
curl https://api.signa.so/health/ready
# -> {"status":"ok","service":"core-api","uptime_ms":12345,"dependencies":{...}}

200

{
  "status": "<string>",
  "service": "<string>",
  "uptime_ms": 123,
  "dependencies": {
    "postgres": {
      "status": "<string>",
      "latency_ms": 123
    },
    "valkey": {
      "status": "<string>",
      "latency_ms": 123
    },
    "opensearch": {
      "status": "<string>",
      "latency_ms": 123
    }
  }
}

Overview

Three unauthenticated endpoints support customer-side uptime monitoring:

Endpoint	Purpose	Typical latency
GET /v1/health	Liveness alias under the /v1 prefix.	Under 5 ms
GET /health/live	Liveness: the process is up.	Under 5 ms
GET /health/ready	Readiness: database, cache, and search index are reachable.	50-200 ms

/v1/health and /health/live are aliases: both return { "status": "ok" } with HTTP 200 whenever the API process is alive. /health/ready runs three real dependency checks and returns per-dependency status and latency.

None of the three require an API key or count against any quota or rate limit.

Suggested poll interval

60 seconds. More frequent polling adds noise without improving signal.

Response: GET /v1/health (and /health/live)

{ "status": "ok" }

Always 200 if the process is running. If the process is down you get a connection error or a 5xx from the load balancer instead.

Response: GET /health/ready

status · string

One of:

• ok: all three dependencies reachable.
• degraded: a non-critical dependency (cache or search index) is down. The API still serves most requests; some features (search, rate-limit headers) may error individually.
• unhealthy: the database is unreachable. The API cannot serve most requests. Returns HTTP 503.
• shutting_down: the task is draining for a graceful stop. Returns HTTP 503 so load balancers route around it.

service · string

Always "core-api".

uptime_ms · integer

Process uptime in milliseconds.

dependencies · object

Show dependencies

postgres · object

Show postgres

status · string

ok or error.

latency_ms · integer

Probe latency in ms (omitted on error).

valkey · object

Show valkey

status · string

ok or error.

latency_ms · integer

Probe latency in ms (omitted on error).

opensearch · object

Show opensearch

status · string

ok or error.

latency_ms · integer

Probe latency in ms (omitted on error).

What this endpoint does not cover

/health/ready reflects API, database, cache, and search readiness. It does not reflect:

• Alert delivery. If your watches stop firing alerts but /health/ready is ok, that’s a sign of a data-sync or evaluation issue, not an API outage. See Troubleshooting.
• A specific office’s data freshness (e.g. USPTO). Poll GET /v1/offices and check each office’s last successful sync instead.
• Your webhook receiver. That’s on your side by definition.

Examples

cURL

# Liveness alias under /v1
curl https://api.signa.so/v1/health
# -> {"status":"ok"}

# Readiness: what your monitoring agent should hit every 60s
curl https://api.signa.so/health/ready
# -> {"status":"ok","service":"core-api","uptime_ms":12345,"dependencies":{...}}

See also

• Troubleshooting: what to check when alerts stop firing despite /health/ready being ok.
• List Offices: per-office sync freshness.