Server monitoring without Prometheus

You want CPU, memory, disk, and temperature on a handful of boxes — and a page when one of them is on fire. You do not want a second full-time job operating the monitoring stack. Here's how to do lightweight server monitoring that works behind NAT, with no open ports, and a real 6 AM incident to show it working.

Prometheus is genuinely excellent, and if you already run it, keep running it. But there's a specific person this guide is for: you have three, or eight, or twenty servers — some at home behind a router, some in the cloud — and you want to know their CPU, memory, and disk, and get alerted when something crosses a line. For that person, standing up Prometheus, Alertmanager, and a fleet of exporters is bringing a datacenter to a knife fight.

What you actually need

Strip it down to the honest requirement and it's short:

• Per-machine vitals — CPU, memory, per-mount disk, temperature, load. The basics that tell you a box is healthy.
• An alert when a vital crosses a threshold — disk over 90%, temperature over 75°C — pushed somewhere you'll actually see it.
• An alert when a machine goes silent — because a server that stops reporting is often the most important signal of all, and it's the one an on-box tool can never send about itself.
• To not open inbound ports — especially for anything behind a home router or CGNAT, where inbound is a non-starter without tunnels and port forwards you'll regret.

Notice what's not on that list: a time-series database, a query language, a scrape config, or a Grafana dashboard you'll admire once and never open again. Those are wonderful for a platform team. They are overhead for watching a homelab.

The heavyweight default: Prometheus + node_exporter

The standard answer is Prometheus scraping node_exporter on each box, with Alertmanager for paging. It works, it's powerful, and it has two costs that hit small setups hard:

• It's three or four services to operate — Prometheus, Alertmanager, an exporter per node, plus alerting rules in YAML. That's real surface area to install, secure, update, and debug.
• It's pull-based — Prometheus reaches in to scrape each node's /metrics port. That means every node needs a reachable, open port and a stable address. For a Raspberry Pi behind a home router, that's port-forwarding or a VPN mesh before you've monitored a single byte.

The other lightweight options each solve part of it: Netdata gives a beautiful per-node dashboard but its cross-node alerting story grows heavy fast; Glances is a superb live top but not an alerting monitor; your cloud provider's metrics only see the VMs you rent from them, never the Pi in your closet.

Flip the direction: push, not pull

Here's the insight that makes the whole problem smaller. Instead of a central server reaching in to scrape each node, have each node push its vitals out to an off-site watcher. Two things fall out of that inversion for free:

• No open ports. The node makes an outbound HTTPS connection, exactly like your browser does. It works behind NAT, behind CGNAT, behind a hotel wifi, with zero inbound attack surface.
• Silence becomes a signal. If a node stops pushing, the watcher notices the gap and pages you — the same dead-man's-switch logic that catches a cron job that never runs. A box that dies can't file its own alert, but its absence is the alert.

Doing it with pylon-beacon

This is what pylon-beacon is: one small static binary you drop on each machine that pushes its vitals out. One command installs it:

josh@home-pi01:~$ curl -fsSL https://pylonmon.com/beacon.sh | sh
✓ downloading pylon-beacon (linux/arm64)…
✓ installed to /usr/local/bin/pylon-beacon
✓ systemd service enabled · pushing every 20s
home-pi01 online · cpu 11% · mem 38% · disk 71% · 47°C

No open ports, no scrape target, no config file to hand-edit. The node registers itself and starts pushing; it shows up in your dashboard within a minute.

Each machine then reports a live vitals card. The built-ins are there, and anything you can print to stdout becomes a custom metric — a site's up/down, a queue depth, SSH failures in the last hour:

The disk bar is amber because it crossed the threshold I set. That's the second half of the job: alerting.

Setting a threshold alert is one rule — page me when disk goes over 90%, temperature over 75°C, or whatever matters. On PylonMon these vital-threshold alerts work on every plan, free included:

Cross the line and it pages your channels; drop back under it and you get the all-clear. Plus, if the whole node goes quiet, the silence alerts you on its own.

Receipts: a real 6 AM incident

Here's this exact setup doing its job on my own boxes, this week, unprompted. At 06:25 UTC, two of my servers each ran their nightly Ubuntu unattended-upgrades — and installing a chunky snapd update pegged a single-core VM. I was asleep. The beacon wasn't:

Caught it, paged, watched it resolve, sent the all-clear — a 20-second event, fully documented, while I slept. That's not a hypothetical from a marketing page; it's a Tuesday.

The point isn't that a patch run is an emergency (it isn't). The point is that a 30-second CPU spike and a server genuinely melting down look identical for the first 30 seconds — and you want the same system watching both, honestly, without you babysitting it. If you'd rather 30-second patch spikes not page you at all, that's a matter of where you set the threshold - not a reason to not monitor.

So, do you need Prometheus?

Straight answer:

• You have a homelab, a side project, or a small fleet, some of it behind NAT — you don't need Prometheus. A push-based beacon gives you vitals, thresholds, and silence-detection with one binary and no open ports.
• You already run Prometheus at scale — keep it, and point it at us. PylonMon ingests Prometheus and Alertmanager alerts, so your existing rules fan out to every channel (Discord, Slack, SMS, webhook) with no per-receiver config, and you get one place for pages plus a public status page on top. Big and on Prometheus is a great fit, not a mismatch.
• You want the best of both — run Prometheus where it earns its keep, drop a beacon on the boxes that don't justify a scrape target, and watch the whole lot from a single dashboard.

Frequently asked questions

How do I monitor a server behind NAT or CGNAT?

Use a push-based agent instead of a pull-based one. The agent makes an outbound HTTPS connection to report its vitals, so there's nothing to port-forward and no inbound firewall rule. pylon-beacon does this; Prometheus, being pull-based, does not without a tunnel or VPN mesh.

Does server monitoring require opening ports?

Only if it's pull-based (like Prometheus scraping node_exporter). A push-based agent opens no inbound ports at all — it connects out, the same way your browser does — which is safer and works behind any router.

What's the lightest way to monitor CPU and memory on Linux?

For a live look, glances or htop. For continuous monitoring with alerts, a single push-based agent is the lightest option that also pages you — one static binary, no database, no dashboard server to run.

Can I monitor a Raspberry Pi for free?

Yes. pylon-beacon ships a native arm64 build (Raspberry Pi 3/4/5 on a 64-bit OS), and PylonMon's free plan covers 3 beacon nodes with vital-threshold alerts included — no credit card. Enough for a typical homelab.

Monitor your servers free →   or read the pylon-beacon overview and the cron-alerting guide.