How to watch a handful of servers without setting up a monitoring stack

What you actually need

For a homelab, a few client machines, or half a dozen services, the requirements are short:

1. Know within a few minutes when something stops answering.
2. Know when it comes back.
3. Have a record afterwards, so “it has been flaky all week” is a claim with evidence.

That is a list of targets, a TCP connect on an interval, and an append-only log of transitions. It fits in a text file and a scheduled task, and it does not need a time-series database, a query language, a dashboard or a container.

Only report changes

The single most important design decision, and the one that separates monitoring you keep from monitoring you turn off.

A tool that prints “host1 OK, host2 OK, host3 OK” every five seconds produces a wall of text that nobody reads, which means nobody notices the line where host2 stopped saying OK. Alert fatigue is not a discipline problem; it is a design problem.

Print transitions. web1 UP → DOWN and, later, web1 DOWN → UP with a duration. Ten lines a month, all of them worth reading.

Check the thing, not the machine

ping proves the network stack is alive. It does not prove the database is accepting connections, and a machine that responds to ping while its service is dead is the most common false negative in this whole area.

Open a TCP connection to the port that matters. That proves something is listening and accepting.

Beyond that there is a progression, and how far you go depends on what failing quietly would cost: a TCP connect, then a protocol-level handshake, then an actual request with an expected response. Each step catches a class of failure the previous one misses. For most small setups, the TCP connect is the right stopping point.

Two settings that matter more than they look

The interval. Every five seconds is not ten times better than every thirty; it is six times the load and roughly the same information. Match it to how quickly you could actually act.

The timeout. Too short and a slow-but-fine host is reported down, teaching everyone to ignore the tool. Too long and one dead host stalls the whole pass. A couple of seconds is usually right on a local network, and more across the internet.

Require two consecutive failures before declaring something down. It removes almost all the noise at the cost of one extra interval of delay.

Recording what you did

A related habit worth having: record the session when you do something significant on a remote machine.

Not a screen recording — the terminal output with its timings, so it can be replayed at real speed. It is a fraction of the size, it is text you can search, and it answers “what exactly did we run during the incident” in a way that memory does not. It is also the easiest possible way to produce a walkthrough for a colleague.

The thing to be careful about is what ends up in it. Terminal sessions collect tokens, keys and passwords with no effort at all, and a recording is a file that gets shared. Scan before you send.

The programs for this

• RemoteDeck is the watchlist: a text file of name host:port, an interval, a timeout, and output that stays quiet until something changes state. --once makes it a scheduled check rather than a resident process.
• SSHDesk answers what your ssh config will actually do for a given host, and why — resolve computes the effective settings, explain names the file and line each one came from. Config files that include other config files and match on patterns are exactly the sort of thing worth having computed rather than reasoned about.
• SessionForge records a command’s output with exact timings and replays it at real speed.
• OpsTunnel is a plain TCP forwarder with per-connection accounting: one agreed hop, and a log of who used it, for how long, and how it ended.

Free while we are in preview, one file each, Windows and Mac.

When to graduate

Move to a real monitoring system when you want history rather than transitions — graphs of a value over time, thresholds on a rate, alerts routed to different people, or more machines than you can hold in your head.

That is a real threshold and it arrives eventually. It is just a long way past five hosts.