Health endpoints
Liveness only answers whether the process can serve HTTP. Readiness answers whether its role can currently serve useful traffic. Configure process restarts from/healthz and traffic admission from /readyz.
The all-in-one listener routes
/healthz to the control plane and /readyz to the data plane. This makes the public
liveness check independent of Postgres while readiness covers the inference path. A data plane that rejects a newer
manifest keeps serving its last accepted snapshot and remains ready.
Metrics
Configure OTLP export, Prometheus scraping, and alerting with the OpenTelemetry guide.Request correlation and logs
Every control-plane and data-plane response carries anairmux-generated UUIDv7 in X-Request-ID. A caller-supplied
value is replaced. Data-plane usage events use the same request ID, including all attempts in a fallback chain.
Production logs are newline-delimited JSON with timestamp, level, logger, event, and message. Logs emitted in
a request context also contain request_id; event-specific bounded fields appear at the top level. Start an
investigation from the response header, then search application logs and usage events for that value. Development mode
uses human-readable logs instead.
CLI diagnostics
doctor first to distinguish local profile, control-plane authentication, and gateway readiness failures.
gateways list needs instance-scoped data-planes.read permission, so run it with an instance-scoped profile or
management key.
Backups
Back up these as one recovery point:- Postgres
- Runtime management credential files
- Provider secret files
- Each gateway’s identity, cached bundles, and SQLite usage outbox