Who observes a beacon

Who observes it

stado host health <target>, stado host beacon list, stado registry doctor, and the read side of the service layer: stado service list joins the declared managed set against the latest beacons and issues no ssh at all. Independent host-beacon reads start together and retain registry order in the result, so one slow store read does not postpone every other host. stado service status <name> first narrows the declarations and reads beacons only for hosts that declare that service; a status lookup does not fetch unrelated hosts or build their unit rows. The beacon join reports unknown when a host has gone quiet; service status of a failed unit separately attempts its exit and stderr reads, carrying those readers' refusals as failure evidence (stado-rs/src/deploy/service/model/managed/status.rs). The autonomy cycle's service reconciliation reads the same documents (operations).

The host's declared service answering probes reuse one HTTP client and connection pool across beacon passes. After a standing-service recovery attempt, Stado cancels its in-flight question before asking again; a hung request cannot retain another task and connection after each attempt. A completed declaration pass also cancels questions and drops answers for services no longer declared on this host. An HTTP client initialization failure appears as a refused cause in the unit's answering reading, not as a healthy process or an absent question. See Service.

For a declared service.answering question, stado service list and stado service status <name> print an answering: <host> <unit>: <reading> line beneath their table. Their --json rows carry the same reading as answering: asked, waiting (with elapsed wait and possibly last), stood (with the host's declared bound), unreadable with the actual catalog, directory or resolver cause that prevented asking, or finished with a result whose state is answered (HTTP status, the HTTP library's successful verdict, elapsed time and the response detail on failure) or refused (the actual transport or request-construction cause). Stado Desktop's Managed services table marks a standing, unreadable, refused or unsuccessful HTTP answer, or one with no HTTP status even if it claims success (including the last result while a new question waits), when process state is active. A malformed answering value, including an answered result without its successful verdict, remains in the CLI's raw JSON row alongside answering_error; the plain table prints answering-error with the decode cause and observed value. Desktop keeps the other fleet rows visible and shows that row-local cause in its table and inspector, rather than treating a missing verdict as a failed or successful HTTP answer.

The beacon's reported_at still governs freshness: a stale reading is historical evidence, not proof that the API answers now.

The read-only real-host journey tests/service_answering/cli.mjs requires STADO_BIN, STADO_TEST_SOURCE_REVISION, STADO_ANSWERING_HOST and STADO_ANSWERING_NAME for a committed build and a declared service. It reads the actual host beacon, a fresh stado host ping verdict, service status and fleet list. It requires a finished answer or a waiting question with a last answered HTTP result whose successful verdict is true, and checks an unknown-name refusal. asked, stood, unreadable, refused, or an HTTP error answer do not prove the API works; a stale beacon does not either. Its command exits, raw responses and hashes are kept under .build/service-answering-cli-*.

Readers resolve a target to its beacon object through the slug rule in monitor/host_health/load.rs — target name, declared hostnames, and their first dot-labels, in order.