Observe a CE instance
Monitor WhoDB's availability separately from the databases it connects to. This lets you distinguish a stopped workspace from a running workspace that cannot reach one source.
Check the process#
Request GET /health. A running WhoDB server returns the plain text ok. Use this for process availability; it does not open every configured database or verify application records.
For a database-path check, use a representative low-cost read from the backend's network. For a CLI connection, whodb doctor --connection <name> --format json provides redacted diagnostics.
Collect useful logs#
| Variable | Purpose |
|---|---|
WHODB_LOG_LEVEL | Choose logging verbosity |
WHODB_LOG_FORMAT=json | Produce structured log output |
WHODB_LOG_FILE | Set the non-HTTP application log destination |
WHODB_ACCESS_LOG_FILE | Set the HTTP access log destination |
WHODB_AUDIT_LOG_FILE | Write append-only NDJSON for supported audited actions |
Choose file paths writable by the WhoDB process. Use your deployment's logging system to collect and rotate them. Restrict access to logs because errors and operational context can contain sensitive information.
Different logs answer different questions. HTTP access logs show requests, application logs help diagnose failures, and the audit destination covers supported audited actions. Do not treat one as proof of every action performed directly against the database.
Investigate an alert#
Record the failing action, its time, selected source, and visible error. Check process health, then the source route, then authentication and query behavior. Correlate the relevant logs before changing settings.
For a slow operation, record result size and compare a small request on the same connection. See Performance tuning. For a failed operation, follow Troubleshooting and server configuration.
Was this page helpful?