Reading your fleet's posture at a glance: node status, grades, and staleness

A single Windows machine tells you one thing: is this box hardened? A fleet asks a harder question — which of my machines are drifting, offline, or ungraded right now? WinSentinel's free tier gives every machine a full-power standalone agent; the Pro control plane turns those agents into a managed fleet. The fastest read on that fleet is the nodes summary rollup.

The one command that answers "how's my fleet?"

The enrolled-nodes table (winsentinel-fleet nodes) is great when you already know what you're looking for, but on a 50- or 100-node fleet it scrolls off the screen. The summary collapses it into four lines you can read in a second:

$ winsentinel-fleet nodes summary
Fleet nodes summary
────────────────────
  Totals:     42 enrolled  •  38 graded  •  4 ungraded
  By status:  active 34  stale 5  offline 3
  Heartbeat:  freshest 40s ago  •  stalest 9d ago  •  1 never seen
  By grade:   A 12  B 15  C 8  D 2  F 1

Everything here is computed client-side from the same /fleet/nodes payload the table uses — no extra round-trip — so it's cheap to run on every check-in.

How to read each line

Totals — is anything unmeasured?

The gap between enrolled and graded is your blind spot. An ungraded node has enrolled and is phoning home but hasn't reported a completed scan yet. Four ungraded nodes means four machines whose posture you genuinely don't know. Dispatch a scan to close the gap:

winsentinel-fleet scan-all --active-only

By status — who's actually reachable?

Status is derived from heartbeat freshness:

• active — checked in recently; commands you dispatch will be picked up.
• stale — missed a few heartbeats. Could be asleep, off the VPN, or a wedged agent. Worth a look.
• offline — silent long enough that you shouldn't count on it. A machine that goes offline and never returns is often one that was decommissioned without being de-enrolled — clean those up so they stop skewing your rollups.

A healthy fleet is almost all active. A creeping stale count is usually the first sign of an agent-deployment or connectivity problem, not a security one.

Heartbeat — how fresh is "fresh"?

The staleness line gives you the extremes: the freshest node (should be seconds/minutes) and the stalest (your worst laggard), plus a never seen count. "Never seen" nodes registered a license but no agent ever checked in — a botched install, or a key that leaked and was activated somewhere it shouldn't have been. Either way, investigate; a node that enrolled but never reported is not protecting anything.

By grade — where's the risk concentrated?

The grade distribution is your triage list. One F and two Ds tell you exactly how many machines need attention before they tell you which ones. Drill into the worst offenders by node id:

winsentinel-fleet node <node-id>

That gives you the per-node posture, open drift alerts, and recent commands so you can decide whether to push a fix or a policy.

Turning the summary into a routine

The rollup is designed to be glanced at daily. A simple operator loop:

1. Read nodes summary. Is active where you expect, and is anything never seen?
2. Close the graded/ungraded gap with a targeted scan-all --active-only.
3. Work the D/F bucket with node <id> drilldowns, then push fixes.
4. Chase stale/offline as an ops problem — a node you can't reach is a node you can't defend.

Prefer machine-readable output for dashboards and scripts? Every summary supports --json, emitting the raw stats object (totals, byStatus, byGrade, and the staleness fields) so you can wire it into your own alerting.

Free WinSentinel makes each machine best-in-class on its own. Fleet rollups like nodes summary are the Pro layer that lets one person keep a hundred of them honest — without reading a hundred reports.

Fleet orchestration — the control plane, remote command dispatch, and rollups like this — is a WinSentinel Pro feature. Single-machine auditing, monitoring, scheduled scans, and PDF reports stay free forever.