The self-hosted monitoring comparison covers Uptime Kuma as the tool for one specific question: is a service actually reachable right now. This guide is the hands-on version. From a single Docker container, you get HTTP, TCP, and ping monitoring, a public status page you can actually share, and a phone notification the moment something stops responding. None of it takes an afternoon. Most of it takes ten minutes.
What Uptime Kuma actually does
Uptime Kuma is a free, self-hosted alternative to UptimeRobot and StatusCake: black-box monitoring that doesn’t care what a service is running on, only whether it answers when asked. It supports HTTP/HTTPS checks (with optional keyword or status-code matching), TCP port checks, ping, DNS record checks, and a growing list of specific integrations like Docker container status and gRPC. It’s MIT licensed, built by the same developer behind Dockge, and it’s one of the most-starred self-hosted projects on GitHub, sitting well past 60,000 stars at this point, which says something about how many people have the exact “is my stuff up” problem it solves. For the license breakdown, the official Docker image, and a side-by-side against similar tools, see the Uptime Kuma app page; the project’s GitHub repository is worth bookmarking directly too, for release notes and the wiki.
Installing Uptime Kuma with Docker
A single container is all it takes:
version: "3.8"
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
volumes:
- uptime-kuma-data:/app/data
ports:
- "3001:3001"
volumes:
uptime-kuma-data:Run docker compose up -d from the folder containing that file, then open http://your-server-ip:3001. The first visit asks for an admin username and password. Set those immediately, since this is the interface that controls every monitor and notification going forward. There’s no separate database to configure and no exporters to install. It just starts.
Adding your first monitors
Every monitor in Uptime Kuma follows the same basic shape: a monitor type, a target, a check interval, and a retry count before it’s flagged as down. A few common setups:
- HTTP(s) monitor: point it at a URL (a homepage, a reverse proxy, an API health endpoint), and optionally set it to look for a specific keyword in the response or accept only certain status codes, so a page that loads but returns garbage still counts as down
- TCP port monitor: useful for services that don’t speak HTTP at all, like a database or an SSH daemon, checking only whether the port accepts a connection
- Ping monitor: the simplest check, good for routers, switches, or any device that should just answer ICMP
- Push monitor: instead of Uptime Kuma checking a target, the target calls a unique Uptime Kuma URL on its own schedule, useful for cron jobs, backup scripts, or anything that should report “I ran successfully” rather than “I’m reachable”
The default 60-second check interval and a retry count of 1-3 works for most homelab services. Dropping the interval lower makes sense for anything genuinely critical, and pushing it higher avoids hammering something like a rate-limited API. Each monitor also gets its own event log, so when something does go down, there’s a timestamped history instead of a vague memory of “it happened sometime last week.”
Monitors can also be tagged and grouped, which becomes useful fast once there are more than a handful running. A “critical” tag on the reverse proxy and DNS server, paired with a shorter check interval and immediate notification, keeps the important alerts from getting buried under a less urgent one for, say, a personal blog nobody’s actively relying on. Uptime Kuma also supports maintenance windows: schedule one before restarting a service or updating the host, and monitors pause instead of firing a false “down” alert during planned downtime.
Setting up a public status page
This is the feature that separates Uptime Kuma from a plain monitoring dashboard: a shareable page showing live status for whichever services are selected, without exposing the admin interface itself.
- Go to Status Pages → New Status Page
- Give it a name and a slug (this becomes part of the public URL)
- Add the monitors that should be visible publicly, grouped however makes sense (e.g., “Media,” “Network,” “Core Services”)
- Customize the page title, description, and optional custom domain
- Publish
The public status page is a separate, read-only view. Visitors see uptime percentages and incident history for the monitors added to it. They never see the admin dashboard, the list of every monitor running, or anything else configured in Uptime Kuma. That separation is what makes it safe to actually share the link with people outside the household.
Multiple status pages and incident notes
Uptime Kuma isn’t limited to one status page. A common pattern is running two: a minimal public one covering just the handful of services that matter to people outside the household, a Jellyfin server shared with family, say, and a more detailed internal one covering everything, kept private or shared only with whoever else administers the homelab. Each status page is independent, with its own slug, monitor selection, and styling, and a custom domain (status.yourdomain.com pointed at the same host) works too, once the reverse proxy in front of Uptime Kuma routes that hostname to the right place.
Status pages also support incident notes: short text updates posted directly on the page during an outage or maintenance window, things like “Investigating elevated latency” or “Scheduled reboot, back by 10pm.” It’s a small feature, but it’s the difference between a status page that just shows a red dot and one that actually explains what’s happening, which matters if anyone besides you is checking it.
Notification integrations: Discord, Telegram, ntfy, and email
Notifications are configured once under Settings → Notifications and then attached to whichever monitors should trigger them. The four most common for a homelab:
- Discord: create a webhook URL in the target channel’s settings, paste it into Uptime Kuma’s Discord notification type, done. Messages show up formatted with the monitor name and status.
- Telegram: create a bot via BotFather, grab the bot token, and add the chat ID of the channel or DM that should receive alerts. Slightly more setup than Discord, but just as reliable.
- ntfy: a lightweight, self-hostable push notification service. Uptime Kuma just needs the topic URL, and no account or API key is required if using the public ntfy.sh server for a private topic name. The ntfy documentation covers self-hosting it too, if keeping notifications entirely off third-party infrastructure matters.
- Email: standard SMTP settings (host, port, credentials), useful as a fallback channel even if Discord or Telegram is the primary one.
Testing each notification type immediately after setting it up is worth the extra minute. A misconfigured webhook fails silently until the moment a service actually goes down, which is exactly the wrong time to discover it.
Exposing the status page without exposing the dashboard
The public status page and the admin dashboard live behind the same Uptime Kuma container, which means exposing one carelessly can expose both. The safer pattern most homelabs land on: put a reverse proxy like Nginx Proxy Manager or Caddy in front of Uptime Kuma on a public subdomain, but restrict access to the /dashboard path (or the admin login) to a specific IP range or VPN. The status page itself, at the root path or /status/your-slug, can stay open to the world since it’s read-only by design.
For the admin side specifically, keeping port 3001 off the public internet entirely and reaching it over a WireGuard tunnel is the more conservative option, and it’s the one worth defaulting to unless there’s a specific reason multiple people outside the network need dashboard access.
Where this fits with the rest of your monitoring
Uptime Kuma answers “is it up,” not “why is it slow” or “how much RAM is it using.” For those questions, it pairs naturally with a metrics tool running alongside it rather than instead of it. The full comparison of when to reach for Uptime Kuma versus Netdata versus Prometheus and Grafana is in the self-hosted monitoring guide. In practice, most homelabs that start with Uptime Kuma because it’s the fastest thing to get running end up adding one of the metrics-focused tools later, once “is it up” stops being the only question worth asking.