Server Monitoring for Home Server — Kuma and Netdata Uptime Setup to Avoid Missing Problems

Some time ago, I realized that the server at home had been down since last night. Either because of a power outage, an automatic update that asks to restart, or a Docker container that suddenly crashes. To be sure, I only found out the next day, when there was a service that couldn't be accessed. It's like parking a car in a dark place without an alarm: you don't know what's going on until you actually check.

From there I began to understand: having a home server is not just a matter of turning on the device and running the service. We also need "eyes" who are always watching, recording conditions, and shouting when something is wrong. Monitoring is not a luxury, it is a very useful little insurance. In this article, I want to share how to setup monitoring for a home server using the two tools I use most often: Uptime Kuma and Netdata.

Why Monitoring is Important, Even if the Server is Only at Home

Before getting into the technical stuff, I want to use a simple analogy. Imagine you have a small coffee shop in front of your house. You can't possibly sit at the cashier 24 hours. So you install CCTV, door alarms, and lights out timers. Server monitoring is similar: you can still sleep peacefully because there is a system that monitors your "digital cafe".

On the home server, monitoring helps us answer several crucial questions:

• Can the website or service still be accessed from outside?
• What is the current percentage of CPU, RAM, and disk usage?
• Are there any processes suddenly consuming excessive resources?
• When was the server down last and for how long?
• Is the SSL certificate nearing its expiration date?

Without the answers above, we would be like driving at night without lights. You may reach your destination safely, but if there is a slight hole in the road, the problem will immediately feel big.

Kuma vs Netdata Uptime: Two Sides of the Blade

When talking about monitoring, confusion often arises: which one to use? In fact, Kuma and Netdata Uptime complement each other, not replace each other.

Uptime Kuma focuses on uptime monitoring. He functions like a security guard who every few minutes knocks on your service door and asks, "Hello, are you still alive?" If there is no answer, Kuma Uptime will record the downtime and send a notification. It is suitable for monitoring HTTP status, ping, DNS, TCP ports, and even Docker containers.

Netdata, on the other hand, is a real-time system monitoring. He is like a doctor who installs a heart rate, blood pressure and body temperature monitoring device on your server. Netdata displays live resource graphs: CPU, RAM, disk I/O, network, processes, and logs. Suitable for performance analysis and in-depth troubleshooting.

When combined, you get a complete picture: Uptime Kuma tells what is down, Netdata helps analyze why it happened.

Preparation: Assumptions and Prerequisites

This article assumes you already have:

• A server or mini PC with Linux installed.
• Docker and Docker Compose already running.
• Access the terminal to run the command.

If you don't have Docker, you can install it first. On Ubuntu or Debian, just run:

sudo apt update
sudo apt install -y docker.io docker-compose-v2
sudo systemctl enable --now docker
sudo usermod -aG docker $USER

Log out and log in again to make the Docker group active for your user.

Setup Kuma Uptime with Docker Compose

Kuma uptime is very easy to run. We just need to create a special directory and a docker-compose.yml file like this:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    volumes:
      - ./data:/app/data
    ports:
      - "3001:3001"
    restart: always

Then run:

mkdir -p ~/uptime-kuma && cd ~/uptime-kuma
# salin docker-compose.yml di atas
docker compose up -d

After the container is running, open a browser and access http://{IP-server}:3001. You will be asked to create the first admin account. After that, start adding monitors.

The most common way is to monitor websites via HTTP(S). Select Monitor Type → HTTP(s), enter the URL, then set the checking interval. A 60 second interval is sufficient for most cases; more often than not it can overload the server and network for no good reason.

Don't forget to set notifications. Uptime Kuma supports multiple channels: Telegram, Discord, Email, Pushover, and even Webhooks. In the Settings → Notifications section, select your favorite provider and do a test notification. Believe me, it's better to be noisy now than silent when the server is completely down.

Netdata Setup for Real-Time Monitoring

Netdata can also be run with Docker, although the native version has more complete features. For home servers, the Docker version is quite powerful and easier to maintain.

services:
  netdata:
    image: netdata/netdata:latest
    container_name: netdata
    hostname: homeserver
    ports:
      - "19999:19999"
    volumes:
      - ./netdata-config:/etc/netdata
      - netdata-lib:/var/lib/netdata
      - netdata-cache:/var/cache/netdata
      - /:/host:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
    restart: always

volumes:
  netdata-lib:
  netdata-cache:

Netdata requires access to the / mount as read-only in order to read host system statistics. Mounting /var/run/docker.sock allows Netdata to see resource usage per container.

Run with:

mkdir -p ~/netdata && cd ~/netdata
# salin docker-compose.yml di atas
docker compose up -d

After that, access Netdata at http://{IP-server}:19999. You will see a dashboard full of graphs: CPU, memory, disk, network, applications, even logs. It may seem busy at first, but over time you'll learn to focus on the metrics that really matter.

Reading the Metrics That Really Matter

From my experience, not all metrics need to be monitored every day. Here are the metrics I pay most attention to:

• CPU usage: if it continues to be above 80%, there are redundant processes or the server is low on resources.
• Memory usage: Full RAM can make the system slow or even activate swap aggressively.
• Disk usage: logs and cache can grow fat without realizing it. Monitor at least the / and /var partitions.
• Load average: shows how busy the process queue is. Ideally, it should not exceed the number of CPU cores.
• Network throughput: helps detect strange traffic or unexpectedly large transfers.

Think of metrics like indicators on a car dashboard. You don't have to stare at it every second, but you have to know which one means "danger" when the lights start to come on.

Sensible Alerting Integration

Monitoring without alerting is like setting an alarm without batteries. Kuma's uptime is enough to tell when a service cannot be accessed. Netdata also has a health alarms configuration, although the setup is a little more technical.

My tip: don't create notifications for every small fluctuation. Too many alerts will make you ignore what is actually important. Starting from the critical: service down, disk full, and CPU load very high. If it's comfortable, add slowly.

Simple configuration example in Uptime Kuma: set retry 3 times with an interval of 20 seconds before an alert is sent. This reduces false alarms due to momentary network disruptions.

Reverse Proxy and SSL for Dashboard Monitoring

To be safer, it is best not to open the monitoring dashboard directly on a public port. I usually close ports 3001 and 19999 from the outside, then access them via an internal reverse proxy or VPN. If it must be accessed from the internet, use at least basic authentication + HTTPS.

If you use Nginx as a reverse proxy, here is an example of a basic configuration for Kuma Uptime:

server {
    listen 443 ssl;
    server_name uptime.lokal.lan;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
    }
}

Replace uptime.lokal.lan with the domain you are using. Don't forget to install a certificate, even if only for the local network. Tools like mkcert are very helpful for internal environments without the need for a public domain.

Backup Monitoring Configuration

One thing that is often forgotten: configuration backup. Uptime Kuma stores all data in the ./data folder. Netdata stores the configuration in ./netdata-config. Make sure these two directories are included in your backup routine.

If you have used restic or borgbackup as I discussed in the previous article, just add the path. Losing your monitor configuration means having to recreate dozens of entries and notifications from scratch.

Conclusion

Server monitoring is not a task that is only important for large companies. On a home server, monitoring is as valuable as electricity and internet connection. Kuma Uptime helps us keep our services up and notifies us when there are problems. Netdata helps us understand the internal conditions of the server in real-time. These two tools, when combined, create a simple but very powerful monitoring system.

If you're just starting out, don't monitor everything right away. Install Kuma Uptime first for important services, add a notification or two, and experience the benefits. Once you're comfortable, then learn Netdata and start monitoring system resources. Like most things in the world of self-hosting, monitoring is a journey, not a final destination.

Have you used Kuma or Netdata Uptime on your server? Or maybe there is another favorite monitoring tool? Write in the comments column, I'd love to hear your experience.