Skip to main content

Health

Two health endpoints ship in v1: an unauthenticated liveness probe and an authenticated canary probe. Both return a small JSON body suitable for direct consumption by uptime checkers and your own deployment smoke tests.

GET /v1/health — public liveness probe

Unauthenticated. No Authorization header is required (and any header you send is ignored).

Response (healthy)

Response (degraded)

Semantics

We return HTTP 503 when status === "degraded" so naive uptime checkers correctly mark the service unhealthy. The response is cached at the edge for 5 seconds (Cache-Control: max-age=5, public). Don’t rely on this probe for sub-second observability; use the Sentry / Datadog spans for that.

When to use

  • Container readiness probes. Kubernetes / Vercel-style checks.
  • External uptime monitors. Pingdom, BetterUptime, etc.
  • Pre-deploy smoke tests. Block a deploy if the canary returns 503.

When NOT to use

  • Per-request latency tracking. Cached for 5 s; the latency you see is bounded by the cache, not by the API.
  • Authenticated canary checks. Use /v1/health/auth instead — that one exercises the auth path too.

GET /v1/health/auth — authenticated canary

Same shape, but the request must carry a valid Authorization header. Use this after a deploy to confirm both the unauth surface AND the API key path are healthy from your client’s perspective.

Response

The body is intentionally minimal — it’s a canary, not an introspection endpoint. For the full workspace + plan + features payload, call /v1/workspaces/me. A 503 here means the same downstream subsystems used by the public probe are unhealthy. A 401 here means the key is bad — investigate that before you investigate the API.

Counted against the rate limit?

Yes — /v1/health/auth consumes from the workspace’s read bucket so a broken canary loop can’t bypass quota. The unauthenticated /v1/health does not count, and is rate-limited only at the IP layer.

Errors

See errors/ for the full catalogue.