Uptime Kuma: a status page in five minutes

May 16, 2026

Picture this: you open your browser, type in the address for your self-hosted notes app, and get a blank page. Is the app crashed? Is the reverse proxy broken? Is it something on your machine? You start SSH-ing into servers, running docker ps, tailing logs. Twenty minutes later you find out the container restarted overnight and never came back up. You had no idea until you actually needed the thing.

That’s the problem uptime monitoring solves — and for a homelab, Uptime Kuma solves it with almost no friction.

What it is, in plain language

Uptime Kuma is an open-source monitoring tool that watches your services and tells you immediately when something stops responding. You point it at URLs, ports, DNS names, or other endpoints, set a check interval, and it does the rest. When something goes down, it sends a notification. When it comes back, it sends another one. It also generates a public-facing (or private) status page so you can share uptime history with others — or just have a single dashboard to glance at.

The whole thing runs in a single Docker container. The UI is clean, modern, and entirely browser-based. There is no config file to hand-edit, no YAML to wrestle with, no database to set up separately. You spin it up, open the web interface, and start adding monitors. That’s it.

The problem it actually solves

When you run one or two services, you can keep track of their health in your head. When you run thirty, you can’t. Services fail for all kinds of reasons: out-of-memory crashes, failed container restarts, certificate renewals that went sideways, a reverse proxy rule that stopped matching. Most of these failures are silent — nothing logs the silence, because logging requires the service to be running.

The only way to know a service is down before you need it is to ask periodically. That’s what a monitor does. It sends a request every minute (or two, or five — your choice) and records whether it got a good response. If three checks in a row fail, you get a notification.

For a homelab operator who also has a job, a family, and a life, this matters. You’re not staring at servers all day. An alert that lands on your phone at 7 AM is infinitely better than discovering the problem at 10 PM when someone else needs the service.

What the commercial options look like

The hosted monitoring market is mature. Services like Pingdom and UptimeRobot (and a dozen others) offer hosted monitoring where you give them your URLs and they check them from distributed locations around the world. The appeal is obvious: no infrastructure to maintain, external vantage points that catch network-level issues you’d miss from inside your own network, and in UptimeRobot’s case, a free tier that covers a reasonable number of monitors.

⚠️ Unverified: UptimeRobot’s free tier specifics (monitor count, check intervals) change frequently — check their current pricing page for accurate figures.

The trade-offs are the usual ones for cloud services: you’re sending your internal service URLs to a third party, check intervals on free tiers are often limited, and anything behind your firewall (internal-only services, private APIs, LAN-only endpoints) can’t be monitored at all without exposing it to the internet first.

If your homelab is mostly public-facing services and you want geographic redundancy in your checks, a hosted option makes sense. If you’re running a stack of internally-accessible services — which is most homelabs — you need something that runs inside your network.

The self-hosted field

There are a handful of self-hosted monitoring tools worth knowing:

Uptime Kuma is the one most homelab operators land on first, and for good reason. The onboarding is nearly zero, the UI is genuinely polished, and it supports a wide range of monitor types (HTTP, TCP port, ping, DNS, Docker containers, and more). Notifications plug into everything — Discord, Slack, Telegram, Gotify, ntfy, email, and many others. The status page feature is built in.

Gatus takes a different philosophy: configuration is entirely YAML-based, which makes it scriptable and version-controllable. It’s more powerful in some ways — you can write conditional health checks, set complex alert conditions, and integrate it tightly into a GitOps workflow. The trade-off is that you’re editing YAML instead of clicking a UI. For operators who prefer infrastructure-as-code for everything, Gatus is worth a serious look.

Healthchecks.io occupies a different niche: it’s designed for cron job monitoring (dead-man’s-switch style), where you send a ping in when something runs successfully and get alerted when the ping doesn’t arrive on schedule. It’s complementary to Uptime Kuma rather than a direct replacement. You can self-host the Healthchecks.io server if you want.

For a homelab getting started with monitoring, Uptime Kuma is the right first tool. You can always layer in Gatus or Healthchecks.io later for specific use cases.

How it fits in this lab

In Sun’s lab, Uptime Kuma runs as a Docker Compose service on a lightweight dedicated virtual machine — 2 GB of RAM and two CPU cores, which is more than it needs. It’s been running since early 2026 with no meaningful resource pressure.

The monitor count sits at around 32 services, mixing two types of checks:

• Internal checks run at a short interval (around 60 seconds) and hit services directly on their internal addresses. Things like the firewall’s management interface, the reverse proxy, the secrets manager, network infrastructure, and core services all get watched this way. These are the checks that fire even if the public-facing stack is broken.

• External checks run at a longer interval (around 120 seconds) and test services through the public-facing URL — meaning they validate the full path: DNS resolution, the reverse proxy, TLS termination, and the app itself. If any link in that chain breaks, the external check catches it even when the internal check still passes.

Running both is intentional. An internal check that passes but an external check that fails tells you immediately where the break is: it’s not the service itself, it’s something in the ingress path.

One monitor worth calling out specifically: Uptime Kuma monitors itself. There’s an entry watching its own endpoint. If Kuma goes down (unlikely but possible), the absence of a check would be ambiguous — but since Kuma is also a Prometheus scrape target in the broader observability stack, there are external signals that would surface a problem anyway.

The status page is configured as a named page that includes all active monitors. It’s used internally as a quick-glance dashboard — the homepage shows a Uptime Kuma widget that pulls live status from the page, giving a single-screen view of the whole stack’s health.

Notifications that actually reach you

A monitor is only useful if the alert gets to you. Uptime Kuma’s notification support is one of its strongest features. It supports a wide list of channels out of the box — you don’t need a separate alerting layer.

In this lab, alerts go to Gotify, which is a self-hosted push notification server. Gotify delivers alerts to a mobile app, so a service failure shows up on a phone within a minute or two of the first failed check. No email delays, no checking a dashboard — it lands the same way a text message does.

The pattern of alerting when something goes down and when it recovers is worth emphasizing. Recovery notifications matter just as much as outage notifications. Without them, you’re left wondering: is the thing I noticed earlier still broken? Did it come back? Recovery alerts close the loop so you don’t spend mental energy tracking open incidents.

Who should set this up

If you’re running more than a handful of self-hosted services and you don’t already have uptime monitoring, Uptime Kuma is the first thing you should add after your services are up. The setup is fast enough that it’s genuinely not worth putting off.

You’re a good fit for Uptime Kuma if:

• You run internal services that can’t be monitored by an external hosted service
• You want to know about outages before users do (even if “users” is just yourself and your family)
• You want a status page without building one by hand
• You value a clean UI over configuration-as-code

You might look elsewhere if:

• You’re already deep in a Prometheus + Alertmanager + Grafana stack and want everything in one ecosystem — Prometheus blackbox_exporter covers much of the same ground in a way that fits naturally into that workflow
• You strongly prefer all configuration in version-controlled files rather than a database-backed UI (Gatus is your tool)
• You’re primarily monitoring cron jobs and scheduled tasks (Healthchecks.io is a better fit)

It’s also worth knowing that Uptime Kuma and a Prometheus observability stack aren’t mutually exclusive. Sun runs both: Kuma handles quick status checks and the human-facing status page, while Prometheus handles deeper metrics, dashboards, and alert rules. They cover different things and complement each other well.

Getting started

The install is short. With Docker Compose, you need roughly five lines:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - uptime-kuma-data:/app/data

volumes:
  uptime-kuma-data:

Bring it up, open the web interface, create an admin account, and add your first monitor. The UI walks you through it. Pick a notification channel, verify it works by triggering a test, then add the rest of your services.

A few things worth doing from the start:

Set both internal and external monitors for public-facing services. The two-layer approach reveals where a break is, not just that a break happened.

Configure notification recovery alerts. Make sure you’re notified when things come back, not just when they fail.

Create a status page. Even if it’s internal-only, having a named page gives you a shareable URL you can pull up quickly or point other people to during an incident.

Don’t over-monitor at first. Start with your most critical services, get the notification pipeline working, then add monitors as you go. A misconfigured monitor that floods you with false positives will train you to ignore alerts.

The short version

If you self-host things and you’re not monitoring them, you’re flying blind. Uptime Kuma is the lowest-friction path from “I have no idea if my services are up” to “I get a phone notification within two minutes of anything going down.” The container is tiny, the setup takes an afternoon, and it runs indefinitely with essentially no maintenance.

It doesn’t replace a full observability stack — metrics, dashboards, and log aggregation are still worth building out over time. But it solves the most immediate problem: knowing when something is broken before you need it. For most homelabs, that’s where to start.

← all posts