Self-Hosting Uptime Kuma on a Raspberry Pi: Monitoring Your Print Farm, Servers, and Shop Network

If you've followed any of the self-hosting guides on this site — Jellyfin, Vaultwarden, Home Assistant, and a handful of others — you've probably ended up with several services running on your network with no single way to tell whether they're actually up. Uptime Kuma is a free, self-hosted status monitoring tool that watches HTTP endpoints, TCP ports, DNS records, and ping targets, and tells you the moment one of them goes down. For a maker shop specifically, it's an easy way to watch your OctoPrint server, NAS, Pi-hole, security camera NVR, and even your CNC's web interface from one dashboard — and get a push notification if your print farm's controller drops off the network mid-job.

Why This Belongs Next to Your Other Self-Hosted Services

Most of the self-hosted stack covered elsewhere on this site — Pi-hole, Home Assistant, OctoPrint, a NAS — fails silently. A service that crashes or a Pi that loses power doesn't send you a text message on its own. Uptime Kuma closes that gap: it's lightweight enough to run happily on a Raspberry Pi Zero 2 W or share a Pi 4/5 with other services, and its own resource footprint is small (well under 200MB RAM for a modest number of monitors).

Installation via Docker

Docker is the simplest path and the one the Uptime Kuma project itself recommends. If you don't already have Docker installed on your Pi, follow the same setup pattern used in our Raspberry Pi home server guide, then run:

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

On a Pi running 64-bit Raspberry Pi OS, the official image pulls the correct ARM64 build automatically. Once the container is running, visit http://<pi-ip>:3001 and complete the first-run setup: create an admin username and password immediately, since this dashboard will have visibility into your internal network's service names and IPs.

Adding Your First Monitors

Each monitor in Uptime Kuma checks one thing on a schedule you set — commonly every 60 seconds for critical services and every few minutes for anything less urgent. For a maker shop, a reasonable starting set looks like:

Monitor TypeExample TargetWhy It Matters HTTP(s)OctoPrint or your print farm dashboardCatch a crashed print server before you walk over to check on a job TCP PortNAS Samba/SSH portConfirms the service is listening, not just that the host pings PingCNC controller or laser cutter's network interfaceMachines with embedded controllers often don't run a web server worth polling — a ping check is enough to know it's alive DNSYour Pi-hole or AdGuard Home instanceIf DNS goes down, every other device on the network loses internet — worth its own dedicated check HTTP KeywordA status page or health endpoint that should contain specific textCatches a service that's technically "up" but returning an error page

Set a reasonable retry count (2-3) before Uptime Kuma marks something down — a single missed check due to normal WiFi jitter shouldn't trigger an alert, but two or three in a row usually means something's actually wrong.

Notifications

Uptime Kuma supports dozens of notification channels out of the box: email (SMTP), Discord and Slack webhooks, Telegram, ntfy, Pushover, and generic webhooks that can feed into Home Assistant or Node-RED for further automation. For a shop setup, pairing Uptime Kuma with the MQTT/Node-RED workflow from our Node-RED automation guide lets a monitor going down trigger something physical — a smart plug power-cycling a hung device, or a status light on your shop dashboard flipping red.

Status Pages

Beyond the admin dashboard, Uptime Kuma can publish a public or internal-only status page — useful if you run a small makerspace or share your shop's network with roommates or family and want a single URL anyone can check ("is the 3D printer server up right now?") without needing admin access to the monitoring tool itself. Status pages are configured separately from monitors and can group services logically (e.g., "Print Farm," "Network," "Media Server").

Backing Up Your Monitor Configuration

All of Uptime Kuma's configuration and history lives in the Docker volume you created (uptime-kuma in the command above) as a SQLite database. Back it up the same way you would any other self-hosted service's data — either with the Restic/Borg approach from our self-hosting backup guide, or with a simple periodic docker cp of the volume to your NAS. It's a small database, so backups are cheap in both time and storage.

Where It Fits vs. Grafana

If you're already running Grafana and InfluxDB from the home weather station guide or a similar setup, you might wonder whether you need both. They solve different problems: Grafana is built for time-series metrics and trends (temperature over a week, print farm utilization over a month), while Uptime Kuma is built specifically for binary up/down status and alerting response time. Running both isn't redundant — Uptime Kuma tells you something is down right now, Grafana tells you why it's been flaky for the past three days.

Once it's running, the honest value of Uptime Kuma is boring in the best way: you stop finding out a service died by discovering it hours or days later when you needed it. For a shop with even a handful of always-on devices, that alone is worth the fifteen minutes of setup.