# Health

Three facts, three calls. Poll them in this order.

## Is the pod up? Is the engine answering?

`GET /api/agents/:id/liveness` → `{ "reachable": true|false|null, "serving": true|false|null }`

- `reachable`: the cluster says the pod exists and is ready. `null` when there is no address yet.
- `serving`: an HTTP request to the pod's address returned something below 5xx. `false` right after creation or a rebuild for about ten seconds while the engine boots; `null` when the connection itself failed.

Rule of thumb: `reachable && !serving` for less than three minutes is booting, longer is broken — call `POST /api/agents/:id/rebuild`.

## Resources

`GET /api/agents/:id/usage` and the `quota` field on the agent:

| field | meaning |
|---|---|
| `memoryUsedBytes`, `memoryLimitBytes`, `memoryPct` | RAM against the plan |
| `diskUsedBytes`, `diskTotalBytes`, `diskPct` | persistent volume |
| `status` (`quotaStatus` on the agent) | `ok`, `warn` (close to the limit), `paused` (over it: the pod is stopped until it is upgraded or freed) |

Numbers refresh about once a minute from the cluster.

## Status of the record

`GET /api/agents/:id` → `status`: `provisioning` while a pod is being built or rebuilt, `running`, `stopped` after pause or an unpaid trial, `failed` when the last build did not come up (rebuild fixes it; data is restored from backup), `deleted`.

## The service itself

`GET /api/status` — whether the deployer behind the API answers. `GET /healthz` — the API process.