Nobody notices when monitoring works. They notice when it doesn't — usually because a client called before your pager did, or because Uptime Robot's free tier only checks every five minutes and your store was down for four of them.
Uptime Kuma is the self-hosted fix that's become the default answer in homelab and small-business circles. ~87k GitHub stars, MIT licensed, one Docker container, and a dashboard that actually looks like someone cared about design. Louis Lam built it because Statping was dying and Uptime Robot wasn't self-hostable. The result is better than "good enough."
What it actually does
Uptime Kuma watches things and tells you when they break. HTTP and HTTPS endpoints, TCP ports, ping, DNS records, WebSockets, Docker containers, even "push" monitors where your cron job checks in — if the heartbeat stops, you get alerted.
The UI is a single-page app over WebSockets, so status tiles update live without refreshing like it's 2014. Each monitor gets response-time history, certificate expiry warnings, and configurable check intervals down to 20 seconds — a lot tighter than most free SaaS tiers.
When something goes red, notifications fan out to whatever you actually read: Slack, Discord, Telegram, email, PagerDuty, ntfy, Mattermost, and roughly 90 other channels. Set up different notification rules per monitor if you want — database down pages the on-call, staging SSL expiry goes to email only.
There's also public status pages. Map a subdomain, pick which monitors appear, share the link with clients or your team. Password-protect it if you'd rather not broadcast internal hostnames to the world.
Why self-host monitoring?
Unlimited monitors, your data. Uptime Robot's free plan caps you at 50 checks and five-minute intervals. Freshping, Pingdom, Better Uptime — same pattern: cheap until you need volume, then monthly bills scale with every endpoint you add. Uptime Kuma costs whatever your VPS already costs.
Internal endpoints. SaaS monitors hit public URLs. They can't ping your private PostgreSQL port, your staging server behind a VPN, or 192.168.1.50:8080 on the LAN. Kuma running inside your network (or on a VPS that can reach those hosts) sees what external probes never will.
Status pages you control. No third-party branding, no "powered by" footer unless you add one. Custom domains, your SSL cert, your uptime history stored locally in SQLite on the volume you mount at /app/data.
It fits the stack you're already building. If you're self-hosting n8n, Immich, and a handful of client WordPress sites, Kuma is the glue that tells you which container died — especially if you mount the Docker socket read-only and watch containers by name.
What running it takes
One container. Seriously.
docker run -d --restart=always -p 3001:3001 \
-v uptime-kuma:/app/data \
--name uptime-kuma louislam/uptime-kuma:2Pin a major version tag in production — :2 or a specific release — rather than :latest if you hate surprise UI changes. The data volume at /app/data holds your SQLite database, monitor config, and notification settings. Back it up. Lose the volume, re-add fifty monitors by hand.
Resource hunger is modest. Homelab guides run it on 512 MB RAM; we'd give a production instance 1 GB for headroom if you're tracking hundreds of checks with 20-second intervals. CPU stays quiet unless you're graphing aggressively or running a huge monitor count.
Put nginx or Caddy in front for HTTPS. Enable 2FA on the admin account — the dashboard shows your entire infrastructure map, which is useful to you and interesting to attackers. If you expose a public status page, that's fine; keep the admin UI behind auth and ideally not on the open internet without IP restrictions.
One gotcha: monitoring from outside Canada when your sites are in Canada adds latency and an extra failure point. We usually run Kuma on the same Canadian VPS or a dedicated monitor box that shares network path with the apps it watches.
Who it's for (and who should skip it)
Good fit: agencies managing multiple client sites, anyone running Docker Compose stacks, MSPs who want a client-facing status page without another SaaS login, homelabbers who've outgrown "I'll notice when something feels slow."
Maybe skip it: if you need full APM — traces, log correlation, synthetic browser tests — Kuma is uptime monitoring, not Datadog. If you won't maintain it (no backups, never update the container), a paid SaaS with someone else's on-call might beat a forgotten self-hosted instance that silently stops alerting.
Hosting it in Canada
We deploy Uptime Kuma alongside client stacks on Canadian Docker hosting — TLS, backups on the data volume, and monitors pre-wired for the sites we manage. Pair it with our n8n setups if you want alert webhooks that trigger actual remediation workflows instead of just pinging Slack.
Tell us how many endpoints you're watching and whether you need a public status page. Sizing is usually trivial; the conversation is more about what to monitor and who gets paged at 2 a.m.
