# 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](https://coordinatordb.com/docs/concepts/features/interfaces/http) and [admission limits](https://coordinatordb.com/docs/reference/settings/server-settings/settings/max).