Status and reliability

Stratix status, reliability, health endpoints, and incident communication.

How to check whether Stratix is healthy, what the platform guarantees, and how to correlate a problem you're seeing with a platform-side event.

Where to check status

Signal	Where	What it tells you
Platform health probes	/health (liveness), /ready (readiness)	Whether the API process is up and its dependencies (database, queue, cache) are reachable — used by the load balancer and Kubernetes probes
Metrics	/metrics (Prometheus)	Request rates, latencies, queue depth, and worker throughput. The platform ships a Prometheus + Grafana stack; operators on Enterprise can scrape it
System info	/api/v1/system/info	Build/version and environment identity for the API you're talking to

The /health, /ready, /metrics, and /api/v1/system/info paths are unauthenticated by design (they back infrastructure probes and scrapers). Every other API path requires auth — see API authentication.

Correlating an issue

Every API response carries a request ID in the JSON body (request_id) and the X-Request-ID response header. When you file a support ticket or read the status page, quote that ID — it lets us trace one request end to end through the gateway, evaluation queue, and workers.

• SDK: the layerlens Python client surfaces the request ID on every response object and on raised errors. See SDK error handling.
• REST: read X-Request-ID from the response headers. See API errors.

What counts as "healthy"

Stratix is an async-first platform. A submitted evaluation, trace ingest, or judge run returns 202 Accepted immediately and is processed by a worker; a green /ready and a 202 mean the work was durably queued, not that it has finished. Poll the resource (or subscribe to a webhook) for terminal status. See async vs sync workflow.

Reliability posture

• Durability. Traces, evaluations, judges, and results persist in PostgreSQL; the ingest and evaluation queues are durable. Work survives a worker restart.
• Rate limits. The API is rate-limited per org and per key; a 429 is a normal backpressure signal, not an outage. Back off and retry — the SDK does this for you. See rate limits and retry & backoff.
• Tenant isolation. One org's load or incident does not affect another — storage is row-level-security scoped and queues are per-tenant. See multi-tenancy.

SLAs by tier

Availability commitments and support-response targets differ by plan. See the pricing tiers — Enterprise includes a contractual uptime SLA and a private status channel.

When something is wrong

1. Confirm it isn't a 429 (rate limit) or an async job still in flight.
2. Check the platform health probes (/health, /ready) if you operate the deployment.
3. Capture the request_id / X-Request-ID.
4. See troubleshooting or contact support with the request ID.