# 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.

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

Response shape:

```json role="response"
{
  "ok": true
}
```




These probes require no device authorization.

| Route | Healthy response | Meaning |
| --- | --- | --- |
| `GET /healthz` | 200 `{ok: true}` | Process is running |
| `GET /readyz` | 200 with `ready: true` | Instance 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 establish**
A 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.