Skip to content
Coordinator DB
View as Markdown
View as Markdown

Check service readiness and SQL access ​

Use two checks to determine whether a Coordinator DB endpoint is usable. An unauthenticated readiness request tests the HTTP listener. A small authenticated SELECT also checks credentials and database selection.

sh
curl --fail --silent http://127.0.0.1:7401/ping
curl --fail-with-body --silent \
  --user "$COORDINATOR_USER:$COORDINATOR_PASSWORD" \
  --data-binary 'SELECT 1 FORMAT csv' \
  'http://127.0.0.1:7401/?database=data'

The readiness response is Ok.. A successful SQL response uses status 200. If HTTP is disabled, test the configured native listener with the supplied client instead.

Interpret the failure stage ​

A connection refusal points to the address, listener or route. A 401 response points to explicit credentials. A SQL error can mean the selected database or statement is invalid. A 503 can indicate connection or request admission pressure rather than a stopped process.

For an external health monitor, choose a bounded check interval and protect stored credentials. Do not use an expensive query as a readiness probe. A healthy response does not certify the correctness of application data or the availability of an unrelated broker or object store.

Coordinator DB has no hosted-service state endpoint. Inspect the process with your deployment tooling when the network endpoint cannot be reached.

See HTTP status codes and admission limits.