Endpoint Health
Returns the latest health-check verdict plus rolled-up uptime statistics for an endpoint. The data comes from the platform's background health-check worker, which periodically probes the endpoint's public hostname.
Health checks must first be enabled for the endpoint via PUT /v1/endpoints/{uuid}/health-check. Endpoints with health checks disabled still respond to this call but the uptime fields will be 0 and last_check will be null.
Path parameters
Response (200 OK)
{uuid} in the path).tunnel (served by an agent) or app (an app's endpoint: static, managed, full-stack, WordPress or function).live, paused (not probed while it lasts) or not_deployed (probed once a deploy is live).up or down. Down only after two failed probes in a row (or a failed first probe); one failed probe after a good one stays up. Omitted before the first probe.true when at least one tunnel-agent is currently connected for this endpoint. For a tunnel target, dashboards typically show "No Agent Connected" instead of the probe verdict when this is false; an app target needs no agent.healthy or asleep (0–100, rounded to 2 decimals).uptime_24h, over the last 7 days.uptime_24h, over the last 30 days.null when no probes have run yet. Fields: status (healthy = the endpoint answered 2xx, 3xx, 401 or 403; asleep = an idle function, not woken by the probe, which counts as up; unhealthy = any other HTTP code; error | timeout = no HTTP answer), status_code (HTTP code, or null on error/timeout), latency_ms, error_message, checked_at.last_check. Used by the admin timeline view; user dashboard ignores this.Deprecated: until the sunset this response also carries the legacy integer endpoint_id and an integer id on each probe. Don't use them; read endpoint_uuid (probes have no public id).
Caching
Uptime aggregates are cached server-side for ~5 minutes; recent probes appear in last_check within seconds because they go through a separate Redis status cache.