Health

GET /health

No credentials required.

{ "status": "ok", "worker": "worker-1-a3f9c2", "databasesOpen": 3 }

Field
status	"ok". If the process cannot answer, you get no response.
worker	Which worker answered. Useful in a support conversation.
databasesOpen	How many databases that worker currently holds open.

What it does not tell you

It does not check object storage. A 200 here does not mean writes are working. This is deliberate: a health check that failed whenever S3 was slow would take the worker out of rotation during exactly the incident where the surviving capacity matters most, and the databases already open keep serving reads regardless.

The practical consequence for you: do not use /health to decide whether the database is usable. It answers “is the process alive”, which is a different and much weaker question. During an S3 outage, /health returns 200 while every write returns 503 storage-unavailable.

If you want to monitor whether the service is actually working, do what we do — issue a real write to a scratch database and look at durability and waitedMs:

curl -fsS "$SQLITED_BASE/v1/databases/$SCRATCH_DB/query" \
  -H "Authorization: Bearer $SQLITED_TOKEN" -H 'content-type: application/json' \
  -d '{"sql":"INSERT INTO _probe (at) VALUES (?)","params":["probe"]}'

A 200 with "durability": "durable" is the only thing that proves the whole path works. waitedMs climbing above its usual ~120 ms is the earliest signal that object storage is degrading.