I remember the exact moment I decided I needed proper monitoring. A service I had been running for years had stopped responding. Not sure exactly when — could have been days, could have been weeks. I only noticed because someone asked me why it was down.
More importantly, it is avoidable.
Everything works until it does not
Here is the thing about self-hosted services. On install day, everything is perfect. You set it up, it works, you move on to the next thing. Days turn into weeks, weeks into months. Updates get applied, servers get migrated, DNS records get changed. And somewhere along the way, something stops working.
It is not anyone’s fault. It is just entropy. Software changes, configurations drift, certificates expire, disks fill up. The silent failures are the worst ones — the service that still responds on port 80 but returns a 500 error, the cron job that stopped running three weeks ago, the database that is about to run out of disk space.
If nobody is watching, you will not know until somebody complains.
A different angle on the same service
One thing I learned over time is that a single monitor is rarely enough. If you run a web server, you might think checking the homepage is sufficient. But what happens when the HTTP-to-HTTPS redirect breaks? Your site loads on a direct HTTPS hit but not when someone types example.com into their browser.
I add multiple monitors for the same service but looking at different angles. A monitor for the canonical URL, one for the redirect chain, one for the specific port. When I migrate a service from one server to another, the old port monitor immediately goes red — that is my reminder to update the firewall or update the DNS before anyone notices.
Misconfigurations happen over time. A network change here, an upgrade there, a firewall rule that gets lost during a server migration. Having monitors at different levels catches these before you forget.
Monitoring is not just for enterprises
There is a common belief that monitoring tools are for big teams with dedicated ops people. That you need a full-time person to manage Prometheus and Grafana before you can know whether your services are up.
I do not think that is true. For a home lab, a small business setup, or a personal infrastructure running a handful of services, you need something much simpler. You need a tool that tells you, in plain language, when something is wrong. And you need it to be easy enough that you actually set it up and maintain it.
A tool you configure once and forget about is infinitely more valuable than a powerful tool you never get around to deploying properly.
What I was looking for
When I started looking for a monitoring solution, I had a few requirements. It needed to be self-hosted — no third-party services storing information about my infrastructure. It needed to be lightweight — I did not want to spin up a separate server just to watch my other servers. And it needed to be simple — I wanted to add a monitor, configure a notification, and move on.
I also wanted something I could automate. Clicking around a dashboard to add monitors gets old when you have dozens of services. I wanted my monitoring configuration to live in the same place as the rest of my infrastructure — version-controlled, repeatable, recoverable.
What I ended up with
I have been using Uptime Kuma for a few years now and I am very happy with it. It is open source, self-hosted, APIs for configuratioand runs in a single Docker container. It checks HTTP endpoints, TCP ports, DNS records, SSL certificates, and more. It sends alerts to Telegram, Discord, email — whatever you prefer. The web UI is clean and intuitive.
This sort of basic monitoring is the entry point to running reliable infrastructure. Grafana, Loki, Prometheus and the rest are powerful tools, but they are also harder to configure and you can easily get lost in the details. A simple monitoring-only tool that does one thing well is a far more useful starting point.
Even if you only run three services — Nextcloud, Home Assistant, and a Samba share — you want something like Uptime Kuma to catch sudden misconfigurations, service crashes, or the port that stopped responding after an update you forgot about.
Once you start monitoring, you end up finding more things to add to it. Your router, your printer, your IPTV device, an energy monitor on your network. It becomes a habit, and a useful one.
Andrea