Skip to main content

Uptime Kuma for Home Servers: Simple Self-Hosted Monitoring That Actually Helps

By MS

Most home servers do not fail loudly.

They fail quietly.

A Docker container stops. A dashboard becomes unreachable. A reverse proxy breaks. A disk fills. A service is technically running, but the web page is dead. You only notice when you actually need it, or when someone in the house complains that “the thing is not working again”.

That is why I like Uptime Kuma.

UptimeKuma monitoring


Uptime Kuma is a self-hosted monitoring tool that gives you a simple dashboard, uptime checks, response times, notifications and status pages without needing a full Prometheus/Grafana setup. The official project describes it as a “fancy self-hosted monitoring tool”, and for a Linux home server or homelab, that is exactly the sweet spot.

This post is split into two parts:

  • Part 1: the short install-and-ready-to-go version;
  • Part 2: the more technical setup with Docker Compose, UFW, reverse proxy, alerts, backups, monitor design and hardening tips.

If you just want Uptime Kuma running quickly, start with the quick install. If you want it to be useful long term, read the technical section too.

Uptime Kuma will not fix your home server. It will tell you when the server starts lying to you.

Related posts:

Quick answer: what is Uptime Kuma good for?

Uptime Kuma is useful when you want to monitor whether things are up or down without building a full observability platform.

Good home server use cases:

  • monitoring local web dashboards;
  • checking Docker services;
  • checking TCP ports like SSH, HTTP, HTTPS or custom app ports;
  • monitoring public websites;
  • checking DNS records;
  • checking ping availability for devices on the LAN;
  • creating a private or public status page;
  • sending alerts to Telegram, Discord, email, ntfy, Gotify or other notification systems.

It is not a replacement for logs, backups, metrics, Prometheus, Grafana, security updates or firewall rules. It is a clean and practical uptime monitor.

Part 1: shortest Uptime Kuma install with Docker

This is the quick install.

It assumes Docker is already installed on your Linux home server.

docker volume create uptime-kuma

docker run -d \
  --restart=always \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma \
  louislam/uptime-kuma:1

Then open:

http://server-ip:3001

Example:

http://192.168.1.20:3001

Create the admin account, then add your first monitor.

That is the fastest version.

The official install documentation uses port 3001 and stores persistent data under /app/data. It also recommends the stable louislam/uptime-kuma:1 Docker tag for normal use.

Part 1.1: quick Docker Compose version

For a home server, I prefer Docker Compose because it is easier to back up, read and recreate later.

Create a folder:

sudo mkdir -p /srv/docker/uptime-kuma
sudo chown -R $USER:$USER /srv/docker/uptime-kuma
cd /srv/docker/uptime-kuma

Create the Compose file:

nano docker-compose.yml

Paste this:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - ./data:/app/data

Start it:

docker compose up -d

Check it:

docker compose ps
docker compose logs --tail=50

Open:

http://server-ip:3001

This is already usable. But I would not stop here.

Part 2: better Uptime Kuma setup for a Linux home server

The quick setup works, but a good homelab setup should also answer these questions:

  • Who can reach the dashboard?
  • Is the data backed up?
  • Are alerts configured?
  • Are you monitoring the right things?
  • Is Uptime Kuma itself too dependent on the machine it monitors?
  • Can you restore it after a disk failure?

Monitoring is not just installing the tool. Monitoring is deciding what failure looks like.

Recommended folder layout

I like keeping Docker services under /srv/docker:

/srv/docker/
  uptime-kuma/
    docker-compose.yml
    data/

This makes backup easier:

rsync -aAX /srv/docker/ /mnt/backup/docker/

It also matches the pattern from the Docker backup post:

Related: Backing Up Docker Containers on a Home Server

Safer Docker Compose file for LAN use

If Uptime Kuma is only for your home network, do not expose it more widely than needed.

Basic LAN-friendly Compose file:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "192.168.1.20:3001:3001"
    volumes:
      - ./data:/app/data
    security_opt:
      - no-new-privileges:true

Replace 192.168.1.20 with your server’s LAN IP.

This binds Uptime Kuma to a specific LAN interface instead of every interface.

If you only want to access Uptime Kuma through a reverse proxy on the same machine, bind it to localhost:

ports:
  - "127.0.0.1:3001:3001"

This is useful when Caddy, Nginx Proxy Manager, Traefik or Nginx is the only thing that should reach Uptime Kuma directly.

Important: after changing Docker port bindings, test from another machine. Do not assume.

nc -vz 192.168.1.20 3001

UFW firewall rule for Uptime Kuma

If you use UFW, allow Uptime Kuma only from your LAN:

sudo ufw allow from 192.168.1.0/24 to any port 3001 proto tcp

Check status:

sudo ufw status verbose
sudo ufw status numbered

If you run Uptime Kuma behind a reverse proxy and bind it to 127.0.0.1, you may not need to allow port 3001 through UFW at all.

Related: UFW Firewall Rules for Home Servers

First monitors to add

Do not add 50 monitors immediately. Start with the things that actually matter.

For a typical Linux home server, I would add these first:

  • HTTP monitor: reverse proxy homepage or internal dashboard;
  • TCP monitor: SSH port on the server;
  • Ping monitor: router or gateway;
  • HTTP monitor: important Docker app like Jellyfin, Uptime Kuma, Grafana or Nginx Proxy Manager;
  • DNS monitor: domain or local DNS resolver if you run one;
  • Certificate monitor: public HTTPS service if you expose one.

Example monitor list:

Router ping              192.168.1.1
Home server SSH          192.168.1.20:22
Reverse proxy HTTP       https://status.example.com
Jellyfin                 http://192.168.1.20:8096
Grafana                  http://192.168.1.20:3000
Public website           https://example.com

This gives you useful visibility without turning the dashboard into noise.

Monitor types worth understanding

HTTP / HTTPS monitor

Use this for websites, dashboards, reverse proxies and web apps.

Good for:

  • homepage checks;
  • status codes;
  • response time;
  • basic web availability;
  • certificate expiry visibility for HTTPS endpoints.

Example targets:

https://example.com
http://192.168.1.20:8096
http://192.168.1.20:3001

TCP port monitor

Use this when you only need to know whether a port is accepting connections.

Good for:

  • SSH;
  • SMTP;
  • database ports, if intentionally reachable;
  • custom services;
  • reverse proxy ports.

Example:

Host: 192.168.1.20
Port: 22

Ping monitor

Use this for devices where ICMP ping is enough.

Good for:

  • router;
  • NAS;
  • Wi-Fi access point;
  • printer;
  • other servers;
  • lab devices.

Be careful: some devices block ping even when they are working.

DNS monitor

Use this if DNS is important in your setup.

Good for:

  • Pi-hole;
  • AdGuard Home;
  • local DNS resolver;
  • public domain resolution;
  • checking if a domain points where expected.

Good monitor intervals for a homelab

Do not check everything every 10 seconds.

For a home server, sensible intervals are usually:

Critical local services: 30-60 seconds
Normal dashboards:      60-120 seconds
Public websites:        60-300 seconds
Printers / lab devices: 300 seconds
Non-critical services:  300-600 seconds

Too many aggressive checks create noise and unnecessary load.

For most homelabs, checking every 60 seconds is already enough.

Retries and false positives

One failed check does not always mean a real outage.

Wi-Fi blips, DNS delays, container restarts and slow disks can create temporary failures.

Use retries before alerting.

A practical home server pattern:

Interval: 60 seconds
Retries: 2 or 3
Retry interval: 20-30 seconds

This avoids being notified every time the network coughs.

Notifications: do this immediately

Uptime Kuma without notifications is just a dashboard you forget to open.

Set at least one notification method.

Common good choices:

  • Telegram;
  • Discord;
  • email/SMTP;
  • ntfy;
  • Gotify;
  • webhook;
  • Slack or Matrix if you already use them.

For a homelab, I like notification methods that are simple and independent from the services being monitored.

Example: if your email server is running inside the same homelab, email alerts may fail during the exact outage you care about.

Your alert path should not depend on the broken thing.

What to monitor first

Here is a practical first-monitor plan.

Monitor 1: router or gateway

Type: Ping
Target: 192.168.1.1

If this fails, your local network or gateway may be down.

Monitor 2: home server SSH

Type: TCP
Host: 192.168.1.20
Port: 22

If SSH is down, you may have a bigger system issue.

Monitor 3: reverse proxy

Type: HTTP(s)
URL: https://your-domain.example

If your reverse proxy is down, many services may appear broken at once.

Monitor 4: Uptime Kuma itself through the normal access path

Type: HTTP
URL: http://192.168.1.20:3001

This is not perfect because the tool is checking itself, but it is still useful for dashboard availability.

Monitor 5: one important Docker service

Type: HTTP
URL: http://192.168.1.20:8096

Replace the port with your real service.

Monitoring Docker containers: useful but dangerous if done badly

Uptime Kuma can monitor Docker containers, but there is an important security detail.

The official Uptime Kuma Docker monitoring wiki notes that a Dockerized Uptime Kuma container cannot access the host by default and needs access to the Docker socket to monitor Docker containers.

That usually means a mount like this:

volumes:
  - /var/run/docker.sock:/var/run/docker.sock

Be careful.

Mounting the Docker socket into a container is powerful. It can effectively give that container a lot of control over Docker on the host. In the Docker security post, I called this out as something to treat like admin access.

Related: Docker Security for Homelab Beginners

My recommendation:

  • do not mount the Docker socket just because it is convenient;
  • start with HTTP and TCP checks first;
  • only add Docker socket access if you really need container-level monitoring;
  • do not expose Uptime Kuma publicly if it has Docker socket access;
  • consider a Docker socket proxy if you want a more restricted design.

For many home servers, HTTP/TCP checks are enough.

Reverse proxy setup

If you want Uptime Kuma at a clean URL like:

https://status.example.com

put it behind a reverse proxy.

The official Uptime Kuma install and reverse proxy documentation notes that Uptime Kuma uses WebSocket, so reverse proxy configuration needs to support WebSocket upgrade headers.

Example Nginx reverse proxy block:

server {
    listen 80;
    server_name status.example.com;

    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;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

If you use Caddy, the official wiki includes a simple Caddy reverse proxy example for Uptime Kuma. Caddy is often easier if you want automatic HTTPS.

For a private homelab, I would often keep Uptime Kuma LAN-only or VPN-only instead of exposing it publicly.

Public status page or private dashboard?

Uptime Kuma can create status pages, which is useful if you want a public or shared status view.

For a home server, think carefully before making it public.

A public status page can reveal:

  • service names;
  • uptime patterns;
  • internal naming habits;
  • what you host;
  • when things are down;
  • some infrastructure details.

For a small homelab, a private status page is usually enough.

Good uses:

  • private family dashboard;
  • LAN-only service overview;
  • personal status page for a VPS;
  • public page only for services already meant to be public.

Uptime Kuma should not only monitor the machine it runs on

This is a classic monitoring problem.

If Uptime Kuma runs on the same server as everything else, then a full server outage also kills the monitoring tool.

That does not make Uptime Kuma useless. It just means you need realistic expectations.

Options:

  • run Uptime Kuma on the main home server for local visibility;
  • run a second small Uptime Kuma instance on a Raspberry Pi, mini PC or VPS;
  • monitor public services from outside the home network;
  • use an external ping/HTTP monitor for your most important public endpoint;
  • send alerts through an external service like Telegram, ntfy cloud, email provider or similar.

For a simple homelab, one local Uptime Kuma instance is fine. For anything important, monitor from outside too.

Back up Uptime Kuma

Uptime Kuma stores its data under /app/data inside the container.

In the Compose file above, that maps to:

/srv/docker/uptime-kuma/data

Back up the whole folder:

rsync -aAX /srv/docker/uptime-kuma/ /mnt/backup/docker/uptime-kuma/

Or create a compressed archive:

cd /srv/docker
tar -czf uptime-kuma-backup-$(date +%F).tar.gz uptime-kuma/

Before major updates, stop the container and back it up:

cd /srv/docker/uptime-kuma
docker compose down
tar -czf uptime-kuma-before-update-$(date +%F).tar.gz .
docker compose up -d

For normal home use, this is usually enough.

Related: Backing Up Docker Containers on a Home Server

Update Uptime Kuma safely

Do not update blindly if Uptime Kuma is important to you.

Simple update process:

cd /srv/docker/uptime-kuma

docker compose pull
docker compose up -d

docker compose logs --tail=100

Check the dashboard after updating.

If you want a safer update:

cd /srv/docker/uptime-kuma

docker compose down
tar -czf uptime-kuma-before-update-$(date +%F).tar.gz .

docker compose pull
docker compose up -d
docker compose logs --tail=100

The official update documentation for Docker follows the same general idea: pull the newer image and recreate the container with the same persistent volume.

Hardening checklist for Uptime Kuma

This is the checklist I would use on a Linux home server.

  • Run Uptime Kuma with Docker Compose, not a random one-off command;
  • store the Compose file under /srv/docker/uptime-kuma;
  • use a persistent data folder or named volume;
  • bind to LAN IP or localhost instead of exposing blindly;
  • use UFW to restrict access if port 3001 is reachable;
  • use a strong unique admin password;
  • do not expose the dashboard publicly unless there is a real reason;
  • avoid mounting the Docker socket unless you understand the risk;
  • configure notifications immediately;
  • back up the Uptime Kuma data folder;
  • test restore before relying on it;
  • monitor from outside the server if the service is important.

Common mistake: monitoring too much too soon

It is tempting to add everything:

  • every container;
  • every port;
  • every device;
  • every DNS name;
  • every dashboard;
  • every external website.

That creates alert fatigue.

Start with important things only:

Router
Home server SSH
Reverse proxy
Important Docker app
Backup target
Public website if you have one

Then add more slowly.

Common mistake: alerts that depend on the broken system

If your alerting method depends on your home server, it may fail when the server fails.

Bad example:

Uptime Kuma monitors mail server
Mail server is down
Uptime Kuma tries to send email through that same mail server
No alert arrives

Better:

  • use an external email provider;
  • use Telegram or Discord;
  • use ntfy or Gotify depending on your setup;
  • test notifications after configuring them.

Always send a test notification.

Common mistake: exposing the admin dashboard

Do not casually expose Uptime Kuma to the internet.

If you need remote access, better options are:

  • VPN access;
  • Tailscale or WireGuard;
  • reverse proxy with HTTPS and extra authentication;
  • public status page only, private admin dashboard.

If the dashboard has Docker socket access, be even more careful.

Useful checks after installation

Check container status:

docker compose ps

Check logs:

docker compose logs --tail=100

Check listening ports:

sudo ss -tulpn | grep 3001

Check UFW:

sudo ufw status verbose

Test from another machine:

nc -vz 192.168.1.20 3001

Check the data folder:

ls -lah /srv/docker/uptime-kuma/data

Example complete Compose setup

This is a good starting point for a LAN-only Linux home server.

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "192.168.1.20:3001:3001"
    volumes:
      - ./data:/app/data
    security_opt:
      - no-new-privileges:true

Start it:

docker compose up -d

Allow LAN access with UFW:

sudo ufw allow from 192.168.1.0/24 to any port 3001 proto tcp

Open:

http://192.168.1.20:3001

Then add monitors and notifications.

Example reverse proxy Compose setup

If you use a reverse proxy, bind Uptime Kuma to localhost:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - ./data:/app/data
    security_opt:
      - no-new-privileges:true

Your reverse proxy then connects to:

http://127.0.0.1:3001

This avoids exposing port 3001 directly on the LAN or internet.

What I would monitor in my own homelab

For a simple Linux home server, I would start like this:

Monitor name                  Type      Target
Router                        Ping      192.168.1.1
Home server SSH               TCP       192.168.1.20:22
Uptime Kuma dashboard         HTTP      http://192.168.1.20:3001
Reverse proxy                 HTTPS     https://status.example.com
Jellyfin or media server      HTTP      http://192.168.1.20:8096
Backup target                 Ping      192.168.1.50
NAS or storage box            Ping      192.168.1.60
Public website                HTTPS     https://example.com

Then I would add notifications.

Then I would wait.

The first week of monitoring is useful because it shows you what is actually noisy.

How Uptime Kuma fits with the rest of the home server stack

Uptime Kuma is not the whole security plan. It is one piece.

A good Linux home server stack looks more like this:

  • UFW decides what can connect;
  • Fail2ban reacts to repeated SSH failures;
  • Lynis audits the system for hardening suggestions;
  • Docker hardening reduces container exposure;
  • Backups let you recover when things break;
  • Uptime Kuma tells you when services go down.

That is why Uptime Kuma fits naturally into this blog’s Linux home server series.

Final thoughts

Uptime Kuma is one of the best first monitoring tools for a homelab because it is simple enough to use immediately and useful enough to keep long term.

The quick install gets you a dashboard in minutes:

docker run -d \
  --restart=always \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma \
  louislam/uptime-kuma:1

But the better setup is not just “install it and forget it”.

The better setup is:

  • Docker Compose;
  • persistent data;
  • LAN-only or reverse-proxy access;
  • UFW rules that make sense;
  • notifications that actually work;
  • backups of the Uptime Kuma data folder;
  • monitors that matter;
  • no unnecessary Docker socket exposure.

A home server without monitoring can be broken for days before you notice.

A home server with monitoring still breaks, but at least it tells you.

And that is already a big improvement.

Recommended next reading:

FAQ

Is Uptime Kuma good for home servers?

Yes. Uptime Kuma is a good fit for home servers because it is lightweight, easy to run with Docker, and can monitor local services, websites, ports, DNS and devices without needing a full Prometheus or Grafana setup.

Should I expose Uptime Kuma to the internet?

Usually no. For a home lab, it is safer to keep the admin dashboard LAN-only, VPN-only, or behind a reverse proxy with strong authentication.

Can Uptime Kuma monitor Docker containers?

Yes, but direct Docker container monitoring may require Docker socket access, which should be treated carefully. For many home servers, HTTP and TCP checks are safer and enough.

Does Uptime Kuma replace backups?

No. Uptime Kuma tells you when something is down, but it does not recover data. You still need backups and restore tests.

Written by MS

MS is a Linux homelab and cybersecurity enthusiast who documents practical experiments with home servers, Docker, firewalls, backups, Lynis, Fail2ban, honeypots and old hardware. The guides on IT Random Stuff are based on hands-on testing, real configurations and lessons learned from running Linux systems at home.

Labels:

Comments

Post a Comment

Popular posts from this blog

OpenCanary Honeypot on Ubuntu: 2026 Home Lab Setup Guide

By MS
I first wrote about OpenCanary years ago, and that old version badly needed an update. The tool is still useful, but the way I would deploy it in a home lab today is different: newer Ubuntu versions, Python 3, Docker as an option, cleaner logging, and no copy-pasted example credentials that look like something someone might actually reuse. This guide is the updated version: how I would set up an OpenCanary honeypot on Ubuntu in 2026 for a small home network or homelab. The goal is not to trap random people on the internet. The goal is to create a quiet internal warning system: a fake service that should never be touched, so any connection to it deserves attention. Important: this is a defensive security guide. Run OpenCanary only on systems and networks you own or have permission to monitor. Do not expose a honeypot to the public internet unless you understand the logging, legal, abuse and maintenance implications. If you are building a Linux home server security setup fro...
2 comments
Read more

Lenovo ThinkPad X250 on Linux: Tweaks, Undervolting, Battery Life and 2026 Update

By MS
I wanted a cheap, small, serviceable Linux laptop. Something light enough to carry, easy enough to repair, and inexpensive enough that upgrades would still make sense. The Lenovo ThinkPad X250 was a good candidate because it has a 12.5-inch form factor, a proper ThinkPad keyboard, SSD upgrade options, replaceable parts, Ethernet, docking support and generally good Linux compatibility. I found one on eBay for around 130€ : an Intel Core i5-5300U model with 8GB RAM , a 128GB SSD , two batteries and an HD screen with a small bruise. The plan was simple: clean it, repaste it, upgrade the SSD, install Linux Mint, undervolt it and see how useful it could still be. This post started as my original 2019 notes about tweaking the Lenovo X250 in Linux. I have now updated it with a 2026 perspective, cleaner instructions, better internal links and a more realistic look at whether this old ThinkPad is still worth using. Related posts: Linux Home Server Security Checklist Docker Secu...
2 comments
Read more

Strong, Unique Passwords Without Losing Your Mind

By MS
Last updated: May 27, 2026 Password Security in 2026: Password Managers, Passkeys & 2FA for Real People Password Security in 2026: Password Managers, Passkeys & 2FA That Actually Work Most people do not have a weak-password problem. They have a reused-password problem. You can invent the cleverest password in the world, but if you use it on twenty websites and one of them gets breached, you suddenly have twenty compromised accounts. That is how most real-world account takeovers happen in 2026. Not elite hackers brute-forcing your login from a dark room somewhere. Just automated credential stuffing using databases leaked years ago from services you forgot existed. One old forum breach becomes access to your email, cloud storage, streaming services, VPN account, and eventually your homelab dashboard because the same password got reused everywhere. This guide explains how to handle passwords properly today: without paranoia, without enterprise co...
Post a Comment
Read more