Skip to content
Subnomic
← Back to blog
Fleet Apr 16, 2026 · Updated Sep 11, 2026 · 3 min read

What one outbound agent can tell you about your fleet

CPU, memory, disk, processes and network from every host — over the same connection that carries access.

Observability has a weight problem. The typical monitoring stack ships a heavyweight agent that pulls in a runtime, a pile of plugins, and a footprint that makes capacity planners wince. On a large fleet, an agent like that isn’t a tool — it’s a tax.

We built the Subnomic agent around a different constraint: it should be the one agent a host needs. A single binary that dials out, reports how the host is doing, and carries access over the same connection. Here is what it sees, and how it stays out of the way.

What it sees

Samples travel over the same outbound connection the agent already holds — every five minutes by default — and each server’s Metrics tab shows the last day at the range you pick. No extra ports and no separate metrics pipeline to stand up.

Why small matters

A monitoring agent that degrades the thing it monitors is a contradiction.

On dense fleets and constrained hardware, footprint isn’t a vanity metric — it’s the difference between an agent you deploy everywhere and one you deploy reluctantly. Coverage everywhere is what makes the numbers trustworthy.

How we keep it lean

Access and observability, together

The real advantage is that metrics and access live in the same agent. When a host spikes you don’t jump between a dashboard and a separate SSH tool — you see the problem and open a recorded terminal from the same page. On the Team tier, alert rules on CPU, memory and disk can open an incident and page whoever is on call.

One agent, one connection

The point isn’t a number on a spec sheet. It’s that the agent you install for access is the same one that tells you how the host is doing — so you can see every host you can reach.

See Fleet, or read how to install an agent.

Enjoyed this? Read more on the Subnomic blog.