fix(fleet): declare cachy-laptop and h0004, whose heartbeats were being dropped #199

Merged

kblack0610 merged 1 commit from fix/fleet-declare-cachy-laptop into master

2026-08-18 13:30:42 +00:00

kblack0610 commented

2026-08-18 13:29:35 +00:00

Owner

Both machines have been pushing to gatus and gatus has been rejecting every push, because neither had an endpoint declared. Last 48h of gatus logs:

 425 x  External endpoint with key=homelab_cachy-laptop not found
1130 x  External endpoint with key=android_h0004 not found

cachy-laptop

It was on every roster the bars use, so the status bar drew it as a permanently red dot - one no amount of uptime could turn green, because the heartbeat had nowhere to land. It read NEVER REPORTED on days the laptop was demonstrably switched on. The group in the rejected key (homelab) is what its systemd identity drop-in actually sends, so that is what is declared.

Also joins fleet-exporter's FLEET_ROSTER, closing half the drift scripts/check-fleet-roster.py reported on its first run.

h0004

A device enrolled in Headwind that the fleet bridge started pushing for automatically - the bridge enumerates Headwind's devices table, so declaring the endpoint is the only step a human has to remember, and forgetting it costs a log line nobody reads rather than an error anyone sees. Declared but deliberately not rostered until someone confirms what it is; rostering a stale enrolment would pin the glyph amber forever.

Left alone on purpose

The other half of the drift - windows rostered for Grafana but not for the bars - turns on whether a machine that is usually off should gate the glyph. That is a decision, not a cleanup.

Verified: check-fleet-roster.py passes in CI mode; all-four mode now reports only the windows item above.

Both machines have been pushing to gatus and gatus has been **rejecting every push**, because neither had an endpoint declared. Last 48h of gatus logs: ``` 425 x External endpoint with key=homelab_cachy-laptop not found 1130 x External endpoint with key=android_h0004 not found ``` ### cachy-laptop It was on every roster the **bars** use, so the status bar drew it as a permanently red dot - one no amount of uptime could turn green, because the heartbeat had nowhere to land. It read `NEVER REPORTED` on days the laptop was demonstrably switched on. The group in the rejected key (`homelab`) is what its systemd identity drop-in actually sends, so that is what is declared. Also joins fleet-exporter's `FLEET_ROSTER`, closing half the drift `scripts/check-fleet-roster.py` reported on its first run. ### h0004 A device enrolled in Headwind that the fleet bridge started pushing for automatically - the bridge enumerates Headwind's devices table, so declaring the endpoint is the only step a human has to remember, and forgetting it costs a log line nobody reads rather than an error anyone sees. **Declared but deliberately not rostered** until someone confirms what it is; rostering a stale enrolment would pin the glyph amber forever. ### Left alone on purpose The other half of the drift - `windows` rostered for Grafana but not for the bars - turns on whether a machine that is usually off should gate the glyph. That is a decision, not a cleanup. Verified: `check-fleet-roster.py` passes in CI mode; all-four mode now reports only the `windows` item above.

kblack0610 added 1 commit

2026-08-18 13:29:35 +00:00

fix(fleet): declare cachy-laptop and h0004, whose heartbeats were being dropped

checks / kustomize-builds (pull_request) Successful in 12s

Details

checks / fleet-roster (pull_request) Successful in 26s

Details

457e95d271

Both machines have been pushing to gatus for as long as anyone has looked, and
gatus has been rejecting every push because neither had an endpoint declared.
In the last 48h of logs:

  425 x  "External endpoint with key=homelab_cachy-laptop not found"
  1130 x "External endpoint with key=android_h0004 not found"

cachy-laptop was on every roster the BARS use, so the status bar drew it as a
permanently red dot - a dot no amount of uptime could ever turn green, because
the heartbeat had nowhere to land. It read NEVER REPORTED on days the laptop was
demonstrably switched on. The group in the rejected key (`homelab`) is the one
its systemd identity drop-in sends, so it is the one declared here.

h0004 is a device enrolled in Headwind that the fleet bridge started pushing for
automatically; the bridge enumerates Headwind's devices table, so declaring an
endpoint is the only step a human has to remember, and forgetting it costs a log
line nobody reads rather than an error anyone sees. Declared so its data lands,
but deliberately NOT rostered until someone confirms what the device is -
rostering a stale enrolment would pin the fleet glyph amber forever.

cachy-laptop also joins fleet-exporter's FLEET_ROSTER, closing half the drift
that scripts/check-fleet-roster.py reported on its first run. The other half -
`windows` is rostered for Grafana but not for the bars - is left alone: it turns
on whether a machine that is usually off should gate the glyph, which is a
decision, not a cleanup.