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/authinstead — 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
/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.