TrustGraph

Browse api referenceAPI referenceAttestationsBind a deviceContent certificatesDevice authorityEdgesEpoch commitmentsExternal signing keysGit signer membershipGraph keysPublic handlesHealth and readinessNodes and account deletionReachabilityRelationship tags

Health and readiness

Distinguish process liveness from service readiness.

Auth: No device authorization.

Request and response

Angle-bracket values describe placeholders, including nested objects and numeric types; these are wire shapes, not captured service data. Replace them before sending.

GET /healthz HTTP/1.1
Host: trust-staging.rebellion.systems

Response shape:

{
  "ok": true
}

These probes require no device authorization.

RouteHealthy responseMeaning
GET /healthz200 {ok: true}Process is running
GET /readyz200 with ready: trueInstance can serve under its configured checks

Liveness does not query the database or migration state. A database outage does not by itself make /healthz fail.

Readiness returns {ready, checks} with named checks for database, migrations and attestation, plus capability information where supplied. Each check has name, status and an optional fixed reason. It returns 503 when the database is unavailable, migrations do not match the required state, or the attestation backend has no verification key. The probe reads state without migrating or writing.

Readiness may expose edgeTags and nodeHandles capability descriptions. Read capabilities before offering optional operations, and still handle a refusal when submitting a request.

Does not establishA successful liveness probe does not establish readiness, a working bind provider or successful proof generation. Readiness reports this instance's configured checks at the time of the request; it is not a signed availability guarantee.
Checked against server 9f47f2d · SDK 12053abLast updated 2026-11-04Edit on GitHub