Server Monitor
The Server Monitor is a live dashboard for your whole fleet. Instead of opening a session and typing top, df -h, and free -m on every box in turn, it collects the essentials — CPU, memory, disk, uptime, load average, and network latency — across all your saved connections and colors each host by how healthy it is. One glance tells you which server is on fire and which is idling.
Think of it as the instrument cluster on a car dashboard: you do not want to pop the hood to check the oil, you want a gauge that goes green, amber, or red.
Opening the Monitor
Section titled “Opening the Monitor”Desktop: click the Server Monitor icon (the heart-monitor glyph) in the sidebar. The monitor opens as a dense, sortable table inside the desktop shell — one row per host.
Mobile: open Settings and tap Server Monitor. The mobile layout shows one card per host with inline gauges and sparklines. Tap a host’s card to open its detail view, with a live history graph, “Now” cards for CPU, memory, disk, and network, per-filesystem usage, and system info.
Both surfaces share the exact same health model, so a host that reads “Critical” on your phone reads “Critical” on your desktop too. Local shells are excluded — the monitor only tracks SSH connections.
Where the numbers come from
Section titled “Where the numbers come from”The monitor has two independent collection mechanisms, and it tells you which one produced each reading with a small “via SSH” or “via Prometheus” source chip.
| Source | How it collects | Needs a live session? |
|---|---|---|
| SSH (default) | Runs lightweight shell commands (cat /proc/loadavg, free -m, df -h /, uptime -p, nproc, plus macOS top/vm_stat/sysctl equivalents) over an already-open SSH session. Each command has a 5-second timeout. | Yes |
| Prometheus (optional) | Scrapes a node_exporter target. If you configure a Prometheus URL in settings, ZestSSH auto-discovers targets and matches them to your saved connections by host, label, or job name. | No |
Separately from stats, ZestSSH runs a lightweight TCP reachability probe against every connection to measure round-trip latency and tell “online” from “offline.” That probe runs whether or not a session is open, so even an un-monitored host shows a latency figure and an online/offline dot.
The upshot: SSH-sourced stats only appear while you have a session open to that host. If a host has no live session and no Prometheus match, its card reads “Stats need an active SSH session or a configured Prometheus target.”
What each metric means
Section titled “What each metric means”| Metric | What it shows | Notes |
|---|---|---|
| CPU | On Linux, the 1-minute load average divided by core count, expressed as a percentage. On macOS, 100 - idle%. | Because Linux CPU is load-derived, a busy multi-core box can read differently than an instantaneous “CPU %” you might expect from top. |
| RAM | Used memory as a percentage of total, with the raw used / total MB shown underneath. | Linux uses free -m; macOS sums active + wired + compressed pages. |
| Disk | Root filesystem (/) usage percentage from df -h /. | Only the root filesystem is tracked, not every mount. |
| Latency | TCP round-trip time to the host, in milliseconds, from the reachability probe. | This is a network probe, not an SSH command timing. |
| Uptime | System uptime, abbreviated to its two most-significant units (e.g. 5d 3h). | Hover to see the full string. |
| Load | The 1-, 5-, and 15-minute load averages. | Shown on the mobile card; read as “how many cores’ worth of work is queued.” |
Severity and thresholds
Section titled “Severity and thresholds”Every gauge is colored the same way, and the per-host severity (the status pill / summary strip) is derived from those same bands so nothing ever disagrees.
Gauge colors (CPU / RAM / Disk):
| Band | Color | Meaning |
|---|---|---|
| Below 70% | Green | Healthy |
| 70% — 90% | Amber | Warning |
| 90% or above | Red | Critical |
Latency colors:
| Band | Color | Meaning |
|---|---|---|
| 100 ms or less | Green | Comfortable for interactive SSH |
| 100 — 250 ms | Amber | Noticeable but usable |
| Above 250 ms | Red | Genuinely laggy |
These latency bands are calibrated for real-world SSH — a healthy LAN or regional link at 60-90 ms reads green, not amber.
Host severity buckets, worst-first, are what the summary strip counts and what the default sort ranks by:
- Offline — a fresh reachability probe came back down and no session is open.
- Critical — any fresh gauge is at 90%+ or latency is above 250 ms.
- Warning — any fresh gauge is at 70%+ or latency is above 100 ms.
- Stale — every reading is older than the freshness threshold and nothing is keeping it current, so none of the numbers can be trusted.
- Healthy — online and fresh with nothing above the warning line.
- Unmonitored — no data from either mechanism yet.
Crucially, a stale reading never masquerades as a live one: gauge and latency severity only count while their own source is fresh. The stale threshold is three times the refresh interval, with a 60-second floor, so a single missed tick on a short interval will not flag a host stale.
Refreshing
Section titled “Refreshing”- Manual: tap the refresh button in the header (or pull-to-refresh on mobile). This re-runs both the reachability probes and stats collection.
- Auto-refresh: off by default. Tap the sync icon and pick an interval — 10, 15, 30, 60, or 120 seconds (30 is the default when you turn it on). Once enabled it keeps running in the background even after you leave the screen, until you turn it off.
- Cached across restarts: the last-known stats are saved locally, so when you reopen the app you see the previous values immediately — de-emphasized (muted color) and labelled “collected X ago” until fresh data lands. A bold amber banner marks genuinely stale data.
Sorting and filtering
Section titled “Sorting and filtering”Mobile: sort by Severity (default, worst-first), Name A-Z / Z-A, or highest CPU / RAM / Disk. Toggle Hide unmonitored to drop hosts with no data, and tap any pill in the severity summary strip to filter to just that bucket. Your sort choice is remembered between sessions.
Desktop: click any column header (Host, Status, CPU, RAM, Disk, Latency, Source) to sort by it; click again to reverse. The severity summary strip at the top doubles as a bucket filter.
Both surfaces draw a small history sparkline from recent samples (up to the last 60, kept in memory while the app runs) — CPU/RAM/Disk on the mobile cards, CPU on the desktop rows — so you can see a trend, not just a snapshot.
Configuring the Monitor in ZestSSH
Section titled “Configuring the Monitor in ZestSSH”- Save the connections you want to watch (they show up automatically — there is no separate “add to monitor” step).
- Open the Server Monitor (sidebar on desktop, Settings on mobile).
- Connect a session to any host you want SSH-sourced stats for. The card fills in within a few seconds of connecting.
- (Optional) To monitor hosts without keeping sessions open, configure a Prometheus URL in settings and let auto-discovery match your
node_exportertargets. - Turn on auto-refresh and pick an interval that suits how closely you are watching.
Common mistakes
Section titled “Common mistakes”- Expecting stats with no session open. SSH-sourced CPU/RAM/disk only appear while a session to that host is connected. Without a session (and without Prometheus), you will still get latency and an online/offline dot, but the gauges stay empty. Connect, or configure Prometheus.
- Reading stale numbers as live. Cached values look real but are muted and carry a “collected X ago” note or a bold stale banner. If it is not brightly colored, it is not live.
- Misreading CPU%. On Linux the CPU figure is load-average divided by cores — it is not the same as the instantaneous CPU% you would see in
htop. Use it as a relative health signal. - Assuming latency reflects SSH speed. Latency is a raw TCP probe, independent of your SSH throughput or session responsiveness.
- Forgetting auto-refresh is on. It keeps polling every host in the background at your chosen interval, which means repeated probes and (for Prometheus) HTTP requests. Turn it off when you are done watching.
Free tier vs Pro
Section titled “Free tier vs Pro”The Server Monitor itself is available on every tier, but SSH-sourced stats depend on having sessions open — and concurrent sessions are capped on the free tier.
| Free | Pro (Squeezed) | |
|---|---|---|
| View the monitor, latency probes, cached stats | Yes | Yes |
| Concurrent SSH sessions feeding live stats | Up to 4 on desktop / 2 on mobile | Unlimited |
| Prometheus source (session-independent) | Yes | Yes |
Because Prometheus does not need an open session, it is the practical way to watch more hosts live than the free session cap allows.
Platform notes
Section titled “Platform notes”- The monitor is designed for Linux and macOS/BSD servers — the remote OS is auto-detected via
uname -sand the right commands are chosen per host. Servers running other operating systems may report some or all metrics as unavailable. - Latency and online/offline status work for any reachable host regardless of OS, since they rely on a TCP probe rather than shell commands.
- Local shell “connections” are never shown in the monitor.
Next steps
Section titled “Next steps”- Split Terminal — keep a couple of servers on screen while you watch the monitor for the rest.
- Snippets — one-tap health commands (
df -h,free -h,journalctl) to dig into a host the monitor flagged. - Broadcast — once you have spotted a fleet-wide issue, fix it across every host at once.
- SSH Connections — set up the saved connections the monitor watches.