Health checks and runners
A health check is the probe that keeps a node’s status current. The runner decides where the probe runs from.
Check types
| Type | Target | It’s ok when | Notes |
|---|---|---|---|
http | Full URL, e.g. https://api.example.com | The server answers. Then 2xx = online, 3xx/4xx = degraded, 5xx = offline. | Follows redirects. Latency ≥ 250 ms = degraded. |
http-auth | Full URL | Like http, sending a token. | The token is a secret on the node, picked by name, sent as Authorization: Bearer. Cloud runner only. Without a token the typical answer is 401/403 and the node is degraded. |
tcp | host:port | The connection opens within the timeout. | Only online/degraded (by latency) or offline. |
dns | name or name | expected-IP | The name resolves. | Reads A records only. With an expected IP: if it isn’t among the results → degraded. |
tls | host or host:port (default 443) | The certificate is valid and trusted. | Shows days to expiry. ≤ 14 days = degraded, expired = offline. |
There is also a pg (Postgres) type: it actually runs a SELECT 1. It doesn’t appear in the UI; set it from a manifest or MCP with type: pg, user, database and authSecretName (the password is read from your vault, never stored).
Timeout
The default timeout is 5 seconds and the UI doesn’t show it. From a manifest or MCP you can set timeoutMs. The dns check has no timeout.
Runners: who runs the probe
| Runner | Runs from | Frequency | Use it for |
|---|---|---|---|
cloud | xNode360’s worker, from the internet | Every 10 minutes on free (every minute on pro) | Anything public: domains, HTTPS endpoints, SaaS APIs. |
agent | The agent, inside your server | Every 30 seconds | Anything private: localhost ports, databases on an internal network, services behind a firewall. |
manual | Nowhere | Never | Things you can’t check: you set the status yourself. |
127.0.0.1 means “the machine running the check”. With the cloud runner that’s an xNode360 server, not yours — which is why the cloud runner rejects private targets (localhost, 10.x, 172.16–31.x, 192.168.x, link-local) and tells you to use an agent.
On the agent, tcp, http and pg are fully supported. For dns and tls, use the cloud runner: on the agent their specific logic (expected IP, certificate expiry) isn’t applied.
When a check fails
- Cloud: the node becomes offline and latency shows “—”. There are no retries: every check cycle is a fresh measurement.
- Agent: if the agent can’t reach the backend, the error stays in its logs and, after 2.5 minutes of silence, its nodes go to
degradedand after 20 minutes tooffline.