Monitoring a Home Server Without Making It a Job

I don’t want a wall of dashboards

Search “homelab monitoring” and you’ll find people with beautiful Grafana walls covered in graphs they check approximately never. It looks impressive. It’s also a hobby inside a hobby, and that’s not what I’m here for. My server runs on an old laptop and the whole point has been a calm setup, not a second job.

So the goal isn’t a giant dashboard. It’s a much smaller question: will I find out when the server is down, full, hot, or failing? If I can answer yes to that without staring at charts, the monitoring is good enough. Everything beyond that is decoration I’d have to maintain.

Key Takeaways

• Tells me when the disk is filling up before it bites.
• Tells me when a service has stopped.
• Watches disk health and temperature on aging hardware.
• Sends a simple alert so I don’t have to go looking.

Disk space is the one that actually bites

If I could only monitor one thing, it’d be disk space. A full disk is the failure I’m most likely to hit, because Immich uploads, yt-dlp downloads, and Paperless archives all quietly grow over time. And a full disk doesn’t just stop new writes. It can corrupt databases and make containers fail in confusing ways.

The check is boring and reliable:

df -h /srv/storage /srv/appdata /

I don’t want to run that by hand, so I put a tiny script on a daily systemd timer that checks usage and only does something when a mount crosses a threshold, say 85 percent. The key word is “only.” Silence is the normal state. I hear from it when something needs attention, never just to confirm things are fine.

Service health: is it actually up?

The second question is whether the services are running. Because everything is in Docker or systemd, I don’t need fancy tooling here. The platform already knows the state. I just have to ask it.

For containers:

docker ps -a --filter "status=exited"
docker ps --filter "health=unhealthy"

If either of those returns a row, something’s wrong. For the services I run as systemd units, like yt-dlp’s timer and qBittorrent from part 7, systemctl is-failed does the same job. I fold both checks into the same little script as the disk check, so one daily run answers “is anything down?” in one shot. No new app required.

SMART and disk health on aging hardware

This is a spare-laptop server, so I’m running on a drive that’s already lived a full life. Drives usually warn you before they die, but only if you’re listening. SMART is the drive’s own self-reporting, and checking it costs nothing.

sudo apt install -y smartmontools
sudo smartctl -H /dev/sda

The smartmontools package ships the CLI and the smartd daemon.

That -H gives a quick pass/fail health summary. The smartd daemon can run longer self-tests on a schedule and shout if attributes like reallocated sectors start climbing. On hardware this old, an early SMART warning is the difference between a calm migration to a new drive and a panicked restore from the backups I set up in part 14. I’d much rather get the boring warning.

Temperature, because it’s a laptop

A laptop crammed into a corner running 24/7 can cook itself, especially during the first big Immich import when the fans never stop. Heat shortens hardware life and causes the weirdest, hardest-to-explain crashes. So temperature is worth a glance, even if it’s rarely a problem.

sudo apt install -y lm-sensors
sensors

lm-sensors reads CPU and motherboard temperature, fan speeds, and voltages from the on-board hardware monitors.

I added a threshold check to the same script: if the CPU package crosses a temperature I’m not comfortable with, tell me. Usually the fix is physical, not software. Better airflow, lifting the laptop off the desk, or cleaning out dust. The monitoring just makes sure I notice the trend before a hot afternoon takes the whole server down.

Simple alerts beat pretty dashboards

Here’s the design choice that keeps this calm: I don’t have a dashboard I check. I have alerts that find me. A dashboard depends on me remembering to look, and I won’t. A push notification doesn’t care whether I remember.

My setup is deliberately humble. The daily script collects its findings, and if anything crossed a threshold, it sends one message. I use ntfy (a tiny publish-subscribe push service that can self-host, or you can use the hosted ntfy.sh), but a plain email via a small mailer is just as good. The shape:

if [ "$disk_pct" -gt 85 ]; then
  curl -d "Disk at ${disk_pct}% on /srv/storage" ntfy.sh/my-private-topic
fi

The rule I follow: no news is good news. If the server is healthy, I hear nothing. The only messages I get are the ones that mean “go do something.” That keeps the signal high and the noise at zero, which is the only way alerts stay useful long-term. An alert channel full of routine pings is one I’ll learn to ignore, and an ignored alert is worse than none.

What NOT to monitor

Just as important as what I watch is what I deliberately ignore. Every metric I track is something I’ve committed to maintaining, so I keep the list short on purpose. The calm server isn’t the one with the most graphs. It’s the one I rarely have to think about.

Things I’m choosing not to monitor:

• Per-second CPU and RAM graphs. Interesting, useless to me. The laptop’s load isn’t the problem I’ll ever hit.
• Network throughput dashboards. I’m not running a service that needs them.
• Application-level metrics for every container. If a service is up and the disk has room, that’s enough.
• Anything requiring me to log into a dashboard regularly.

I tried the “monitor everything” path early and quickly realized I was tending the monitoring more than using the server. Stripping it back to four checks and one alert channel was the move that kept this a tool instead of a chore.

When should I add more monitoring?

That’s monitoring that fits a calm server: four things worth watching, one alert channel, and a strong bias toward silence. With backups, careful remote access, and now monitoring in place, the boring trust layer under the whole build is finally done, and the server can just disappear into the corner and work. For the small annoyances and early mistakes, and what I’d do differently starting this spare-laptop server over from scratch, part 11 is the checkpoint I keep revisiting. For the full map, the series index collects every part in order.