Building Fleet Monitoring from Smaller Pieces

If a machine was healthy earlier and the next attempt can’t reach it, there is still a successful observation in the history. Treating that as the current result would give me the wrong answer.

I have a first beta of Fleet Status Monitoring to show. It’s part of something I’ve been exploring: taking a familiar software problem apart, looking at the pieces I already have, and seeing how much of the usual solution I actually need.

For this one, I wanted a useful view of my systems. What had been checked? Was the information recent? Was something running short of memory or disk space? If a system couldn’t be checked, I wanted to see that too.

I’m using Swamp’s workflows and versioned data to put those pieces together. The current release is 2026.11.09.1 on the beta channel. This is an early version of the idea, with a demo you can download and explore.

See the beta

The demo uses Fleet’s unchanged assessment, validation, report renderer and filtering controls from the released beta, rather than the earlier prototype or the separate dashboard-report-view package. You can filter the systems, inspect a low-disk warning and an access gap, then switch to an example where an observation has gone stale.

All the systems, measurements and timestamps are synthetic. The example runs offline, has no live backend, and disables live refresh. It shows how the released code handles those states; it isn’t evidence of a scan of my infrastructure.

The download includes an interactive HTML example and a 50-second, caption-led video assembled from screenshots of actual interactions with it. Unzip the bundle and open index.html to try it, or watch.html for the video. You don’t need an account or server.

To install the beta extension:

swamp extension pull @jpisgeek/fleet-status-monitoring --channel beta

Starting with the job

The familiar route would be to choose a monitoring platform, connect the machines, and build a dashboard inside it. I wanted to work back from the questions instead. Which observations did I need? What made them trustworthy? What did a person need to see?

Finding the smaller pieces

The job breaks down into an inventory of intended targets, observations from those targets, rules for assessing them, and a readable view of the result.

The collector records what it can observe. Policy decides what needs attention. The report shows the assessment and the evidence behind it. Keeping those separate means a threshold can change without rewriting the probe, and the page doesn’t have to invent its own idea of health.

For local collection, the beta uses native OS APIs for memory, load, uptime and other available measurements, with bounded reads for OS metadata and filesystem capacity. Remote collection uses the official SSH behavior, configured separately for exact targets. The Fleet extension itself starts no subprocess and installs no monitoring agent.

The related dashboard-report-view extension takes the presentation idea further: a producer supplies an explicit snapshot of sections, rows, states and evidence, and the renderer makes it readable.

Making a failed check visible

The interesting part isn’t just getting a number onto a page. It’s deciding what the page should say when the next check fails.

The real Fleet workflow starts a scan identity. Collection belongs to that scan, and rendering checks that the evidence matches. A missing or failed attempt becomes a visible gap. A newer malformed result cannot quietly fall back to an older success.

The report also preserves the observation time. Reloading a page doesn’t make its underlying information new.

This is a useful place to rethink the primitive. A green status needs an observation, a time and a policy behind it. Otherwise I’m just moving uncertainty into a nicer-looking interface.

Keeping the awkward details

Working closer to the observations still leaves the operating system details to deal with.

On macOS, the native probe checks the startup data filesystem. Mounted installers and disk images aren’t additional data disks, and volumes sharing APFS capacity shouldn’t be added together as if their capacity were independent.

Load remains load, rather than being relabeled as CPU utilization. An observed OS version doesn’t prove patch currency or support. Windows product version, load and capacity remain unavailable in the native probe instead of being filled with guesses.

A known disk warning can still appear when another measurement is unavailable. The report also distinguishes fresh OS coverage from complete health coverage. Those limits belong in the result, where I can see them.

What I still have to own

For this status-snapshot workflow, I can use the pieces already in Swamp without requiring a separate monitoring platform. I still depend on Swamp, its runtime and the operating systems. Real remote collection needs SSH configuration. A live report needs an authenticated host, and I have code to maintain.

The live refresh path is deliberately narrow: the host authorizes the request and runs one configured, input-free workflow. The browser doesn’t receive server credentials or choose arbitrary commands.

The beta starter workflow is manual and unscheduled. Pulling the package doesn’t start a server or install a native dashboard page. I can run the workflow, inspect its result, and then decide whether to schedule it. Its bounded runtime history is not a backup strategy.

What I want to keep exploring

This is the part that interests me beyond a fleet page: being able to question the shape of an accepted solution without pretending the engineering underneath has disappeared.

I want to keep trying that approach on real problems. Before adding another system, work out what it would actually do for me. Then see whether the useful part can be built from something simpler that I already understand.