Operations
Health, readiness, diagnostics, and API-served support pages.
These routes are exposed by the control plane — the gateway also exposes the status routes.
Status checks
| Method | Route | Purpose |
|---|---|---|
GET | /healthz | Process liveness. |
GET | /readyz | Readiness. Reports database state when configured. |
Liveness
GET/healthz→ 200
Process liveness. No authentication.
curl https://api.s46.dev/healthzconst health = await fetch("https://api.s46.dev/healthz").then((r) => r.json());health = requests.get("https://api.s46.dev/healthz").json(){ "status": "ok" }Readiness
GET/readyz→ 200 / 503
Readiness, with database state when a database is configured. Returns 503 if the configured database cannot be reached.
curl https://api.s46.dev/readyzconst ready = await fetch("https://api.s46.dev/readyz").then((r) => r.json());ready = requests.get("https://api.s46.dev/readyz").json(){ "status": "ok", "database": "ok" }{ "status": "ok", "database": "disabled" }{ "status": "unavailable", "database": "unavailable" }Browser support routes
Consumers normally do not need these — they back the API-rendered auth pages.
| Method | Route | Purpose |
|---|---|---|
GET | /assets/auth.css | Stylesheet used by the API-rendered auth pages. |
GET | /session · /session/ | Session handoff shell. Does not expose a share payload. |
The JSON session stream used by clients is GET /v1/sessions/{sessionId}/stream?team={team} — see Teams & sessions.