Uptime Kuma: Self-Hosted Monitoring That Actually Gets Used

Every production system goes down eventually. The question is whether you find out from your monitoring tool or from an angry user. Uptime Kuma is the self-hosted answer to that question — a monitoring tool that runs on your own server, checks your services around the clock, and alerts you the moment something breaks.

With over 76,000 GitHub stars it's the most popular self-hosted uptime monitoring tool available, and for good reason. The setup takes minutes, the interface is genuinely nice to use, and it covers the monitoring scenarios that actually come up in production.

What Uptime Kuma is

Uptime Kuma is an open-source self-hosted monitoring tool created by Louis Lam. It monitors the availability of websites, APIs, TCP ports, DNS records, Docker containers, databases, and more — running continuous checks and alerting you through 90+ notification channels when something goes down.

The project is MIT licensed, runs on Node.js, and is distributed as a Docker image. It stores data in SQLite by default, with PostgreSQL and MariaDB support added in v2.0. Resource requirements are minimal — a small VPS or even a Raspberry Pi handles it comfortably.

Version 2.0 released in October 2025 brought a refreshed UI, MariaDB support, rootless Docker images, and a reworked data model. Version 2.1 in February 2026 added Globalping integration for worldwide monitoring probes and domain expiry monitoring.

Monitor types

Uptime Kuma covers a wide range of check types:

• HTTP/HTTPS — basic availability check, with configurable expected status codes and response time thresholds
• HTTP keyword — checks that a specific string appears (or doesn't appear) in the response body. Useful for detecting when a page loads but returns an error state.
• HTTP JSON query — evaluates a JSONPath expression against the response body. Good for API health endpoints that return structured status data.
• TCP port — checks that a port is open and accepting connections
• Ping — ICMP ping with latency tracking and charting
• DNS record — verifies that a DNS record resolves to an expected value. Catches misconfigured or hijacked DNS.
• Push — the monitor sends a heartbeat to Uptime Kuma on a schedule; if the heartbeat stops, an alert fires. Ideal for monitoring cron jobs, background workers, and services that aren't publicly reachable.
• Docker container — monitors container status directly via the Docker socket
• Database — MySQL, PostgreSQL, MariaDB, MSSQL, Oracle, Redis, MongoDB connectivity checks
• SSL certificate — monitors certificate expiry and alerts before it expires
• Domain expiry — added in v2.1, monitors domain registration expiry dates
• Steam game server — yes, really. Useful if you're running game servers.
• Globalping — v2.1 integration with the Globalping network for running checks from multiple locations worldwide, useful for detecting regional outages

Notifications

90+ notification channels is not an exaggeration. The practically relevant ones for most teams:

• Slack, Discord, Telegram, Microsoft Teams
• Email (SMTP)
• PagerDuty, OpsGenie, Alertmanager
• Pushover, Gotify, ntfy
• Webhooks (for custom integrations)
• Apprise (which itself supports 50+ services)

Multiple notification channels can be attached to a single monitor, and you can configure per-channel escalation — for example, send a Slack message immediately, but only trigger PagerDuty after 3 consecutive failures.

Status pages

Uptime Kuma includes a public status page feature. You create a page, assign monitors to it, and get a clean public URL showing uptime history for your services. Visitors see whether your services are operational without needing to log into the monitoring dashboard.

Status pages are customizable — logo, colors, domain — and support maintenance windows so you can schedule planned downtime and show it on the status page rather than triggering alerts.

Self-hosting

Docker Compose is the cleanest deployment path:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    ports:
      - "3001:3001"
    volumes:
      - uptime-kuma:/app/data
    restart: always

volumes:
  uptime-kuma:

Open http://localhost:3001, create your admin account, and you're monitoring. Total setup time under 5 minutes.

A few things worth configuring after setup:

• Reverse proxy with SSL — put Nginx or Caddy in front so the dashboard is accessible over HTTPS
• 2FA — enable in Settings → Security. Your monitoring dashboard contains a full map of your infrastructure; protect it accordingly.
• Backups — in v2.x the JSON backup/restore feature was removed. Use volume backups instead: stop the container, back up the uptime-kuma volume, restart.

Where Uptime Kuma fits in your stack

Uptime Kuma is an uptime and availability monitor, not a full observability platform. It answers "is this service up?" and "how fast is it responding?" — not "what is the CPU doing?" or "why did this request take 3 seconds?"

For most teams it fits alongside rather than instead of tools like Prometheus + Grafana or SigNoz. The typical setup:

• Uptime Kuma — external-facing uptime checks, public status page, alert routing
• Prometheus + Grafana / SigNoz — internal metrics, tracing, detailed performance data

If you're only running one monitoring tool, Uptime Kuma punches above its weight for simple to medium-complexity setups. If you're running a serious production stack, it's a useful complement to a more comprehensive observability platform.

What it doesn't do

Worth being clear about the limitations:

• No distributed monitoring by default — checks run from your server only. If your server goes down, your monitoring goes down with it. Globalping integration in v2.1 partially addresses this for public endpoints.
• No built-in incident management — no on-call scheduling, no escalation policies, no incident timeline. For that you need PagerDuty, OpsGenie, or similar.
• No metrics or tracing — uptime and response time only. Not a replacement for Prometheus or an APM tool.
• Single node — no clustering, no HA for the monitoring service itself. For critical infrastructure monitoring, you want either redundancy or a managed service.

Uptime Kuma vs alternatives

vs Pingdom / Better Uptime / StatusCake — these are managed SaaS services with multi-location monitoring, incident management, and on-call scheduling built in. They're better for teams that need those features and don't want to run their own infrastructure. Uptime Kuma wins on cost (free beyond server expenses) and data ownership.

vs Nagios / Zabbix — Nagios and Zabbix are far more powerful and far more complex. They monitor infrastructure at a much deeper level. Uptime Kuma is significantly easier to set up and maintain, but covers a narrower scope.

vs Prometheus + Alertmanager — different tools for different purposes. Prometheus is a metrics platform; Uptime Kuma is an uptime checker. They complement each other more than they compete.

My take

Uptime Kuma is one of those rare tools that does exactly what it says, does it well, and doesn't make you configure YAML for an hour before it works. For anyone running self-hosted services — whether that's a homelab, a small production stack, or internal tooling — Uptime Kuma is a straightforward answer to "how do I know when things break?"

The 76,000 GitHub stars are earned. It's actively maintained, the v2.x release cleaned up the rough edges, and the Globalping integration in v2.1 addresses the single biggest limitation of self-hosted monitoring. If you're not monitoring your services yet, this is where to start.

Need help setting up Uptime Kuma?

Getting Uptime Kuma into production — Docker setup, reverse proxy with SSL, notification routing, status page configuration — is straightforward if you know what you're doing. If you'd rather skip the setup, Pipoline can handle it. Get in touch and we'll figure out what makes sense for your stack.