Abstract purple and amber illustration representing self-hosted uptime monitoring

Uptime Kuma

Uptime Kuma is a free, open-source, self-hosted monitoring tool: point it at a website, an API, a server, or a Docker container, and it checks that target on a schedule, charts the results, and alerts you the moment something goes down. It runs as a single Docker container behind a modern, reactive dashboard, the kind of interface usually reserved for paid tools like UptimeRobot or StatusCake. None of that data leaves hardware you control.

License: Uptime Kuma is licensed under the MIT License, confirmed directly from the LICENSE file in the louislam/uptime-kuma GitHub repo, not assumed from a badge.

Quick facts: Official site uptime.kuma.pet · GitHub louislam/uptime-kuma, 86,000+ stars · Current release 2.3.2 · Docker image louislam/uptime-kuma on Docker Hub, 100M+ pulls, recommended tag :2 (the project’s own Docker Hub page calls the :latest tag “deprecated and bad practice”).

Why self-host your uptime monitoring?

Cloud status-check services work fine, but every URL you monitor and every outage you’ve ever had sits on somebody else’s servers, and free tiers usually cap how much you can watch and how often. Uptime Kuma exists because of that gap: its own README explains that its creator wanted a self-hosted tool like UptimeRobot, and the closest option at the time, a project called statping, had gone unstable and unmaintained. So he built his own and released it under the MIT License in 2021. It’s since become one of the most-starred projects in the self-hosted space.

What Uptime Kuma actually monitors

A single instance covers more than a basic ping check. Monitor types include HTTP(s), TCP ports, HTTP(s) with keyword or JSON-query matching, WebSocket, Ping, DNS records, Push (for external heartbeat checks), Steam Game Servers, and Docker containers checked through the Docker socket directly, with intervals as tight as 20 seconds.

When something fails, alerts go out through 90+ notification services, including Telegram, Discord, Slack, and email. Uptime Kuma also tracks TLS certificate expiry, supports two-factor authentication, works behind a proxy, and can publish multiple public status pages mapped to their own domains.

Installing Uptime Kuma with Docker

The project publishes an official image on Docker Hub, past 100 million pulls. One command gets a running instance:

docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2

For anything meant to stick around, the project’s own docker-compose.yaml is the cleaner starting point:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "3001:3001"
docker compose up -d

Either way, Uptime Kuma is reachable at http://your-server-ip:3001 afterward. Note the tag: the project’s Docker Hub page recommends :2 over :latest, which it calls “deprecated and bad practice,” and a smaller :2-slim variant exists too.

Skip network file systems for the data volume. The official install docs are explicit that “File Systems like NFS are NOT supported” and to map a local directory or a Docker volume instead, or the SQLite database underneath can corrupt.

First run: your admin account and first monitor

  • Open http://your-server-ip:3001. Uptime Kuma ships with no default login; you set the admin username and password yourself on first visit.
  • Click Add New Monitor, choose a type (HTTP(s) is the default), point it at a URL or host, set a check interval, and save.
  • Go to Settings → Notifications and connect at least one channel, Telegram, Discord, or email, before you actually need an alert.
  • Turn on two-factor authentication under Settings → Security if the dashboard will ever be reachable outside your LAN.
  • Optional: add a Status Page for a public or family-facing view that doesn’t expose the admin dashboard.

Hardware: Uptime Kuma runs light, with an embedded SQLite database by default and no separate database container to manage. A Raspberry Pi, an old mini PC, or a spare core on a NAS handles dozens of monitors at 20-second intervals without strain. Still deciding what to run it on? Our homelab setup guide for beginners covers the trade-offs.

Homelab use cases

The obvious first move is monitoring everything else already running: Home Assistant, Pi-hole or AdGuard Home‘s DNS resolution, a Jellyfin or Nextcloud instance, anything with an IP address. One dashboard becomes the place that shows what’s actually up, instead of finding out a service died when you happen to try using it.

Notifications don’t have to stop at a chat message. Point a webhook at n8n and a downtime alert becomes a workflow: restart a container, log the outage, escalate differently at night. A public status page is also a clean way to tell family a shared service is down without handing them dashboard access.

Uptime Kuma: pros and cons

  • Free and open source under the MIT License, no paid tier, no monitor cap beyond your own hardware
  • Fast, real-time dashboard over WebSocket instead of a page that reloads every few minutes
  • Broad protocol support (HTTP(s), TCP, DNS, Ping, Docker, Steam servers) plus 90+ notification integrations
  • Single container with an embedded database, nothing extra to provision for a first deploy
  • No built-in high availability; an instance monitoring your homelab is a blind spot if that homelab loses power
  • Public status pages need your own domain to look fully professional
  • 90+ integrations make the notification list long to search the first time
  • No official mobile app; checking status means the web dashboard or a third-party client

Alternatives worth knowing about

UptimeRobot and StatusCake remain the obvious cloud alternatives if running infrastructure just to monitor infrastructure isn’t appealing, both offer free tiers with no server required. Uptime Kuma’s own README credits UptimeRobot as the direct inspiration: its creator wanted a self-hosted equivalent after finding the closest existing option, statping, no longer maintained.

On the self-hosted side, Gatus and Healthchecks.io take a more config-file-driven approach, YAML instead of a dashboard. Worth clarifying directly: uptimekuma.org is not the official website, despite ranking near the top of search results. Its own About page admits it: an unofficial fan site, unaffiliated with the actual author. The only official links are uptime.kuma.pet and github.com/louislam/uptime-kuma.

FAQ

Is Uptime Kuma really free?

Yes. It’s MIT licensed with full source on GitHub, no paid tier exists, and there’s no monitor cap in the software itself, only whatever the hardware running it can handle.

Is uptimekuma.org the official website?

No. The project’s GitHub repository lists uptime.kuma.pet as the official site. uptimekuma.org describes itself on its own About page as an unofficial fan-built website, unaffiliated with the author.

Can Uptime Kuma monitor Docker containers directly?

Yes. Docker Containers are a built-in monitor type, checking a container’s running state through the Docker socket, alongside the usual HTTP(s), TCP, and Ping checks. If those containers are managed through Portainer, the two pair naturally: one deploys and organizes them, the other watches that they stay up.

Uptime Kuma ends up being one of the highest-value single containers in a homelab: once it’s running, it’s the thing that tells you whether everything else actually is. Our homelab setup guide for beginners covers the Docker basics it depends on, and if Home Assistant, Pi-hole, AdGuard Home, or n8n are already running, monitoring them is a five-minute add. The Monitoring and Docker & Containers categories round out the rest of the tooling here.