Proactive Monitoring & Findings

Solo & Teams

Servonaut watches your fleet for real problems — disk filling up, a service that died, a certificate about to expire, someone hammering SSH — and hands you each one as a triageable finding card with severity, evidence, and, where it's safe, a one-click fix you confirm before it runs.

How it works, in one line

Detection runs in the Servonaut cloud. Your machine only runs read-only probes over your relay and renders the results — and a fix only ever executes on an explicit human click, from a server-signed preview. Nothing is analysed, decided, or changed on your servers without you.

The Findings inbox

Findings live in the TUI. There are two ways in:

Fleet-wide — open 🛡 Findings in the sidebar for one inbox across every instance, with status and severity filters (f / v) and paging.
Per-instance — press F on any server's action screen to see just that box's findings.

Each card shows what was found, how serious it is, the supporting evidence, and any remediation options. Status changes sync back to Servonaut, so everyone on your team sees the same inbox.

Running a scan

Press s to scan. Live per-detector progress streams into the panel as it runs. A scan dispatches read-only probes to your machine over your relay connection — and the TUI starts that relay automatically, so in normal use there's nothing to set up by hand: open the TUI, press s, done.

Detectors that don't apply to a given box aren't silent failures — they're reported with the reason (for example, no database credentials saved, or no Docker present), so you always know what ran and what was skipped.

Scanning outside the TUI

You only need to start the relay yourself if you're running without the TUI — on a headless box, from a script, or to keep a listener alive in the background. In that case, start it from the CLI:

servonaut connect          # foreground relay
servonaut connect --bg     # background listener
servonaut connect --status # check whether the relay is live

Scans need a live relay

"Scan now" and one-click remediation both run over your relay — that's how a read-only probe or a confirmed fix reaches your server. The TUI keeps it connected for you; if the relay ever drops, the scan button tells you instead of hanging. Only headless use needs servonaut connect.

What Servonaut detects

Detectors are chosen automatically based on what each server actually runs — a box with no database is never scanned for slow queries. Coverage today:

Detector	What it catches
Disk pressure	Filesystems running low on space, and the biggest directories driving it.
Service health	Failed or dead `systemd` units, crash loops, and units the kernel had to OOM-kill.
System errors	Error-level journal entries and out-of-memory events grouped by unit.
Slow database queries	Long-running or heavy queries on databases whose credentials you've saved to the vault.
Suspicious traffic	Web-traffic anomalies and SSH credential-scanning — cross-referenced against `fail2ban` so already-blocked sources aren't re-flagged (see below).
Container problems	OOM-killed, crash-looping, or unhealthy Docker containers.
TLS certificates	Certificates that are expired or expiring soon.
Pending updates	Outstanding OS package updates, including security updates.

The set grows over time; new detectors light up automatically for the servers they apply to, with nothing to install or configure on your side.

Triaging a finding

Open a finding with enter to read its evidence, then act on it:

Key	Action	Meaning
`a`	Acknowledge	You've seen it and you're on it — keeps it in the inbox, marked.
`r`	Resolve	It's dealt with. (Applying a one-click fix resolves it for you.)
`x`	Suppress	Don't surface this one again — for known-and-accepted conditions.

Every status change syncs server-side, so your team's inbox stays consistent no matter who triaged what.

Gated one-click remediation

Some findings carry an automatable fix — those show a Run action. The flow is deliberately boring and safe:

Preview. The server returns the exact command it wants to run, as a signed preview. You see precisely what will happen before anything does.
Confirm. You approve it. Anything that changes state on the server requires a typed confirmation, not just a keypress — so a fix is never one stray tap away.
Run. The confirmed command runs over your relay through a fixed, allow-listed executor. Your client never builds, guesses, or free-forms a command — it can only run the specific, pre-approved action the server signed.
Audit. Every execution (and every dry-run) is written to your local audit trail.

A dry-run preview is available first on fixes that support it, so you can see the effect without committing to it.

Nothing runs on its own

There is no autopilot. A remediation only ever executes from an explicit human click on a server-signed preview. Servonaut will never change something on your server without you confirming the concrete action first.

Blocking an attacking IP

When a finding identifies a source that's scanning or attacking a server, the one-click fix blocks that IP. Servonaut picks the right mechanism for where the box lives:

On AWS — via WAF, a Security Group, or a Network ACL.
On any other server — via the box's own firewall: nftables, ufw, or firewalld, auto-detected.

The preview shows the exact IP and method (for example, blocking 203.0.113.10 at the host firewall) before you confirm. The block records how it was applied so it can be reversed later.

Renewing a certificate

A TLS-expiry finding can offer a one-click certificate renewal. As with any state-changing fix, you get the signed preview and a typed confirmation first, and the run is audited.

fail2ban-aware detection

If a server runs fail2ban, Servonaut reads its current state while analysing SSH activity. Sources that fail2ban has already banned are treated as mitigated and don't clutter your inbox — so a finding about SSH scanning highlights the attackers your existing defences haven't caught. That's usually the more useful signal: it surfaces the gap rather than repeating what's already handled.

The safety model

Detection is remote; execution is local and gated. The cloud decides what to suggest; your machine only runs read-only probes and the one fix you explicitly confirm.
Read-only by default. Probes are limited to a read-only allow-list — the same three-tier guard system as the MCP server.
Fixes are allow-listed, not generated. The client can only execute the specific server-signed actions in the remediation allow-list. It cannot be talked into running arbitrary commands.
Everything is audited. Probe runs, previews, and executions are all recorded to your local audit log.

Plans & availability

Proactive monitoring is included with the Solo and Teams plans, with a monitored-instance allowance. On the Free plan the Findings panel shows an upgrade card. See Pricing for the current allowances.

Previous Servonaut AI Next MCP Server