A homelab status page with Uptime Kuma

What you get: a clean, self-hosted status + uptime dashboard — “are my services up?” at a glance, with history, notifications, and an optional public status page — running in a lightweight Proxmox container. Uptime Kuma is the easiest win in homelab monitoring: one container, a friendly UI, and dozens of check types (HTTP, TCP, ping, DNS, Docker, database, etc.).

---

1. Deploy it (Docker LXC)

An unprivileged Docker LXC is plenty — Uptime Kuma is tiny (a couple hundred MB):

# on the PVE host
pct create 100 local:vztmpl/debian-12-standard_*.tar.zst \
  --hostname uptime --cores 2 --memory 1024 --rootfs local-lvm:8 \
  --net0 name=eth0,bridge=vmbr0,ip=192.168.15.143/24,gw=192.168.15.1 \
  --features nesting=1,keyctl=1 --unprivileged 1 --onboot 1
pct start 100
pct exec 100 -- bash -c 'apt-get update && apt-get install -y curl && curl -fsSL https://get.docker.com | sh'

Compose (persist the DB in a named volume so upgrades are painless):

# /opt/uptime/docker-compose.yml
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    restart: unless-stopped
    volumes: ["uptime-kuma:/app/data"]
    ports: ["3001:3001"]
volumes: { uptime-kuma: {} }

docker compose up -d

Browse to http://CONTAINER_IP:3001, create the admin account, done.

2. Put it on a real hostname (reverse proxy)

Front it with your proxy — uptime.example.com → http://192.168.15.143:3001 + TLS, and (recommended) LAN-only for the admin UI. Add a local DNS record so the hostname resolves internally. If you run a wildcard cert, it just works. (Uptime Kuma’s dashboard returns a 302 to /dashboard when you hit the root — normal.)

3. Add monitors + a status page

• Monitors: add checks for each service — HTTP(S) for web apps, TCP for databases/SSH, ping for hosts, plus the handy specialized ones (Docker container, Postgres/Redis, DNS record). Set intervals + retries.
• Notifications: wire up ntfy / Discord / email / Telegram so you hear about outages, not just see them.
• Status page: create a public (or LAN) status page grouping your services — great for a household “is the internet/Plex/etc. up?” screen, or a public trust page for hosted sites.

---

The one design rule people get wrong

Don’t run your monitor on the same node as the things it monitors.

A monitor that dies with its target tells you nothing — if the host hangs, Uptime Kuma hangs too, and you get silence instead of an alert. So on a single-node homelab it’s fine to start there, but plan to move Uptime Kuma onto a separate node (a Raspberry Pi, a second mini-PC, or another cluster node) so it survives the outage it’s supposed to report. It’s the cheapest reliability upgrade you can make.

Nice extras

• Homepage (gethomepage.dev) as the front door with live widgets (Proxmox, Pi-hole, UniFi, Docker) and an Uptime Kuma widget embedded — one screen for everything.
• Add Prometheus + Grafana + a Proxmox exporter later if you want graphs/metrics; Uptime Kuma covers the “up/down + alert” 90% on its own.

Written from a working deployment: Uptime Kuma in an unprivileged Docker LXC on Proxmox, LAN-only behind Traefik, alongside a Homepage front door — with a note-to-self to relocate the monitor to a separate node once the cluster exists.