My Mac fleet dashboard learned Windows. The hard part was knowing what not to count.
Published
Mixed fleet · architecture diagram
Windows has routes, not assumed coverage
Mac/Linux collector, private Windows bridge, and optional native sender feed identity-checked private snapshots and the viewer. Windows routes are alternatives, not duplicate computers. Diagram, not installed-host inventory.
- MAC / LINUX Existing health collector Feeds private snapshots for the viewer.
- WINDOWS · ROUTE A Approved private WinRM bridge Existing operator-selected access; no new enrollment implied.
- WINDOWS · ROUTE B Native sender → private receiver Optional ingest-only path; merge by stable identity.
- COVERAGE GATE Pending ≠ pilot ≠ automatic No connection → pending. An accepted pilot stays a pilot until task readback and a natural scheduled sample verify more.
The dashboard started with Macs and Linux machines. Then the obvious question arrived: why should Windows computers live in a different mental inventory?
On October 14, I released the Windows path in macfleet-dash. That is a source-release claim, not a declaration that every computer I own is now monitored automatically. The difference is most of the story.
A dashboard can make a disconnected computer look reassuringly present. Give it a card, a location label and a green-looking total, and inventory starts to look like evidence. This update is designed not to do that.
What actually shipped that day
The work landed in a sequence of public releases:
| Release | What changed | What it does not prove |
|---|---|---|
| v0.7.0 | Resource panels, hourly history, retained local Hermes usage counters, and a prepared Windows one-shot pilot | A Windows installation or fleet-wide token accounting |
| v0.8.0 | Fleet groups, intersecting location filters and an optional private Windows bridge | Successful unattended polling on a particular computer |
| v0.9.0 | Optional private receiver and native Windows sender/installer, with identity-checked merging | Deployment approval, startup persistence or scheduled operation |
| v0.9.1 | Actionable warnings, per-drive free space, clock direction and a bounded retry for a timed-out listener scan | Clock repair or permission to turn an invalid security check into a pass |
These are viewer releases. The original health collector and probe remain at v0.6.0. A new viewer version does not mean all the running services need a restart.
This article covers the October 14 work. The subsequent v0.9.2 release belongs to October 15, not this day’s build log.
Two Windows routes, not a new public control plane
The first route uses an existing, operator-selected private WinRM connection. The bridge runs the reviewed collector in memory and publishes a snapshot for the viewer. It does not install a Windows agent, open a listener, change a firewall, enroll a VPN client or manufacture access that wasn’t already there.
The second route is an optional native sender. It sends the local collector’s readings to a private Tailscale receiver. The receiver is ingest-only and pinned to stable device identities; it is not a remote-control service. Persistent installation remains an operator-specific approval and verification step.
Here is the architecture without any real machine names or addresses:
The versioned Windows documentation explains the transport and installation boundaries. This is intentionally not a public internet monitoring endpoint.
A pilot is not automatic monitoring
I want three different answers from this system:
- Source released: someone can inspect and use the implementation.
- Installed or manually exercised: a specific computer has the approved setup, or has produced an accepted reading. Those are host-specific facts.
- Naturally verified: the expected later scheduled sample arrived without someone manually running the command; startup behavior needs its own check too.
The receiver’s automaticVerified setting defaults to false. An accepted reading is a pilot until native task readback and a naturally scheduled update support something stronger.
That isn’t bureaucratic wording. A task can exist and never run successfully. A manual command can work in an interactive session while the same command fails in a background job. Even the private-network CLI can behave differently in its scheduled context.
I am not publishing an installed-host count or a verified automatic-coverage count here. The public releases do not establish either one.
The boring arithmetic matters
The useful fixes are not all glamorous.
A healthy data drive cannot rescue a full system drive. Windows fixed drives are shown individually. Adding free space across drives can make the total look comfortable while the drive that matters is nearly full. v0.9.1 brings each drive’s available capacity onto the card instead of requiring a trip into details.
A machine’s clock and the arrival of its reading are different facts. The bridge preserves the original Windows timestamp and the authenticated receipt time. A clock ahead of the receiving computer gets a clock warning, not a fictional fresh timestamp. Failed polls keep the last successful times rather than pretending the failure was a new reading.
Identity is not a display name. Malformed and conflicting identities are rejected. Changing a target must not inherit another computer’s old metrics. Reboots invalidate cross-boot network rates.
Unknown isn’t zero. Missing readings, incomplete history and pending inventory stay visibly incomplete. Filters intersect without duplicating computer counts. The warnings should explain what needs attention, not congratulate me for having a list of computers.
Where AI fits honestly
This is AI-assisted development, not an AI deciding whether a computer is healthy. The release notes identify Codex preparation; the behavior lives in inspectable PowerShell, Python and JavaScript.
There is also a useful connection to daily AI operations: v0.7.0 reads retained local Hermes session/model counters for the computer running the token publisher. Input, output and cache counters remain separate. Unclassified sources and incomplete coverage remain visible.
Those counters are not provider invoices, daily allocations, usage from every computer or proof of savings. The opt-in completion benchmark is separate again: a benchmark request is not passive live throughput.
The practical AI lesson is to demand explicit state boundaries from generated work. A fluent explanation of a scheduler is cheap. A scheduler producing the next real sample is the evidence.
What I’d keep
One private dashboard for a mixed fleet is useful. One undifferentiated green status is not.
If you try this project, begin with the reviewed one-shot collector on a confirmed computer and use existing protected access. Validate the identity and the actual readings before considering persistent installation. Then verify the natural next update and startup behavior separately. Don’t widen a listener just to make a screenshot easier.
The part worth copying is not the card design. It is the refusal to count a prepared script, a pending inventory entry or a successful manual pilot as an automatically monitored computer.
Public references
- macfleet-dash source and current README — current HEAD may describe later work.
- Change log frozen at v0.9.1 — the October 14 release sequence described here.
- Windows setup and verification boundaries at v0.9.1.