Running a growing number of self-hosted services is only worthwhile if you actually know when one of them breaks. Rather than finding out a service is down because I happened to try using it, Uptime Kuma sits watching everything continuously and alerts immediately when something stops responding.
Why Uptime Kuma
There are plenty of monitoring options — Nagios, Zabbix, PRTG, various SaaS status page tools. Uptime Kuma won out for being genuinely simple to run (a single Docker container), having a clean modern web UI, and supporting exactly the monitor types a homelab actually needs — HTTP(S), TCP port checks, ping, DNS, and Docker container health — without the operational overhead of a full enterprise monitoring stack that expects a dedicated team to run it.
Deployment
Running as a Docker container on the Synology NAS, alongside the other containers covered in the Synology writeup:
services:
uptime-kuma:
image: louislam/uptime-kuma:latest
container_name: uptime-kuma
volumes:
- /volume1/docker/uptime-kuma:/app/data
ports:
- "3001:3001"
restart: unless-stopped
Persisting /app/data to a bind mount means monitor configuration and history survive container updates and restarts cleanly — an easy thing to overlook, since a container updated via Watchtower without a persistent volume would silently wipe every configured monitor on its next image pull.
What’s being monitored
A mix of monitor types across the whole homelab:
HTTP(S) checks — confirms services actually respond correctly, not just that the port is open:
https://blog.omnitrix.uk — expected status 200
Proxmox web UI (10.0.0.10:8006) — expected status 200
TCP port checks — for services without a web interface:
TrueNAS iSCSI (10.0.10.1:3260)
SSH on UniFi gateway (10.0.0.1:22)
Ping checks — basic reachability for network infrastructure:
UniFi CG Fibre gateway
Proxmox host
Synology NAS
Docker container monitors — watching the health status of individual containers directly via the Docker socket, catching a crashed container even if the underlying host is still up and would otherwise pass every other check type cleanly.
The distinction between an HTTP check and a plain TCP/ping check matters more than it first appears — a web server process can be alive enough to accept a TCP connection while returning 500 errors on every request, which a simple port check would report as “up” while the actual service is unusable. Preferring HTTP status checks wherever a service has a web interface catches that failure mode; TCP and ping checks are reserved for things that genuinely don’t expose one.
Alerting
Notifications are configured per-monitor, so critical services (the public blog, Proxmox itself) can alert immediately while less critical internal tools use a longer grace period to avoid noise from brief blips:
Notification channels:
- Discord webhook (immediate, all monitors)
- Email (critical monitors only, after 3 consecutive failures)
Retry interval: 60 seconds
Retries before alert: 3
Requiring 3 consecutive failures before alerting avoids false alarms from a single dropped ping or a brief network hiccup, while still catching genuine outages within a few minutes. The 60-second retry interval is a deliberate balance too — tighter intervals catch outages faster but add meaningfully more request volume against every monitored endpoint, which matters for the public blog specifically since Uptime Kuma’s own checks show up in the same access logs used for the Security page’s traffic analysis.
Status page
Uptime Kuma also generates a public or private status page summarising everything at a glance — useful both as a personal dashboard and as something that could eventually be shared if any of these services had other users depending on them:
https://status.omnitrix.uk (internal only, not exposed publicly)
Kept internal-only deliberately for now — a public status page for a personal homelab mostly just tells an attacker what’s running and whether anything’s currently degraded, which isn’t information worth handing out for free until there’s an actual audience who benefits from seeing it.
Result
Every meaningful service across the homelab — the public blog, Proxmox, storage, network infrastructure — is now watched continuously, with alerts landing in Discord within a couple of minutes of anything actually going down, rather than discovering an outage by accident days later. Combined with the live security monitoring on the blog itself, this closes the loop on actually knowing the state of the whole environment at any given time, not just assuming everything is fine because nothing’s complained recently.