/health endpoint is a lightweight liveness probe you can call without any authentication. It tells you whether the daemon process is up, what version is running, how long it has been alive, and whether API key enforcement is active. Use it from monitoring systems, load balancers, shell scripts, and CI pipelines.
Endpoint
X-Substrate-Key header is required. The endpoint always returns 200 OK as long as the daemon is alive and its internal HTTP server can accept connections. If you receive any connection error or non-200 status, treat the daemon as unhealthy and restart it.
Response Fields
Always
"ok" when the daemon is healthy. Future versions may return "degraded" if non-critical subsystems are failing.Semantic version of the running daemon binary, e.g.
"1.0.0". Use this to verify you are running the expected release before automated deployments.Number of seconds since the daemon process started. Useful for detecting unexpected restarts — a value that resets to a low number means the daemon crashed and recovered.
Number of OS processes the daemon is currently tracking. A value of
0 means no applications have been detected yet; the daemon may still be scanning or no supported runtimes are running.Whether API key authentication is enforced on all other endpoints. When
false, you may omit X-Substrate-Key headers everywhere. Check this during initial setup to confirm your daemon configuration matches your intent.Examples
Expected Response
Notes
- If the daemon is starting up,
/healthmay refuse connections for up to 2 seconds while the HTTP server binds its port. Retry with a short backoff before declaring the daemon unhealthy. - The endpoint does not probe the health of individual runtime probes. A healthy
/healthresponse does not guarantee that all tracked processes are producing valid state — checkprobe_statusper app viaGET /apps. - Calling
/healthdoes not count against any rate limit and does not appear in per-key usage metrics.
