Uptime Kuma — 90 Alert Channels, Zero Monthly Fees, One Docker Container

Uptime Kuma crossed 89,600 GitHub stars by July 2026. Version 2.0 landed in October 2025 with MariaDB support and a full UI overhaul; v2.1 followed in February 2026, shipping Globalping integration — multi-location checks from dozens of probes worldwide — and domain expiry monitoring. Created by Louis Lam under the MIT license, the project still costs nothing and runs in a single Docker container using about 50 MB of RAM. If you already pay for a VPS and you are not monitoring your services, you are out of excuses.

What Uptime Kuma actually checks

The scope goes well beyond what Uptime Robot offers on its free tier. Uptime Kuma covers twelve monitor types with no volume caps:

• HTTP/HTTPS with configurable expected status codes, response time thresholds, keyword presence or absence in the response body, and JSONPath queries for API health endpoints that return structured status data.
• TCP and Ping for services that do not speak HTTP — databases, MQTT brokers, game servers.
• DNS with record value verification, useful for catching hijacking or propagation errors before users notice.
• Docker containers monitored directly through the Docker socket, no HTTP port exposure needed.
• Databases — MySQL, PostgreSQL, MariaDB, MSSQL, Oracle, Redis, MongoDB — checking that the connection succeeds and the engine responds.
• SSL certificates with pre-expiry alerts, plus domain WHOIS expiry added in v2.1.
• Push monitors (heartbeat) for cron jobs, async workers, and internal services that are not publicly reachable.
• Globalping — integrated since February 2026 — running the same checks from multiple worldwide vantage points, ideal for catching geo-specific outages or confirming availability from other regions.

Check intervals range from 20 seconds to several hours. The dashboard shows latency and uptime charts over a rolling 90-day window with per-minute granularity.

90 notification channels, and the ones that matter

Uptime Kuma’s killer feature is that it does not force you into a channel you are not using. The 90 integrations cover every platform actually deployed in 2026:

• Chat — Telegram, Discord, Slack, Microsoft Teams, Matrix, Google Chat, Rocket.Chat, LINE, WeChat, Zulip, Mattermost.
• Push and mobile — Gotify, Ntfy, Pushover, Pushy, OneSignal, Pushbullet.
• Email via SMTP, SMS via Twilio, Vonage, ClickSend, SMS Partner.
• ITSM and on-call — PagerDuty, OpsGenie, Alertmanager, SIGNL4, Squadcast, Splunk On-Call.
• Webhooks for wiring anything custom, plus Apprise support which multiplies the destination count further.

Each monitor can be attached to multiple channels with escalation rules — for instance, a Slack message fires instantly, while PagerDuty only triggers after three consecutive failures. You can also set up a dead man’s switch via a heartbeat monitor on an external service like Healthchecks.io: if Uptime Kuma itself stops emitting, you get notified that your monitoring went dark.

Status pages that do not look hacked together

Uptime Kuma ships a built-in status page generator — public or private. A status page displays the uptime history of whichever services you choose to expose, with a clean, responsive design — custom logo, colors, custom domain.

Maintenance windows are handled natively: schedule a planned intervention, the page displays « scheduled maintenance » instead of a red alert, and notifications are suppressed for the duration. The result is a status page hosted on your own infrastructure that looks closer to Better Uptime or Atlassian’s Statuspage than to a side-project weekend build.

One compose file, five minutes

The install fits in a ten-line compose.yaml. v2.x stores everything in SQLite by default; PostgreSQL and MariaDB are available for larger deployments.

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

volumes:
  uptime-kuma-data:

docker compose up -d

Open http://localhost:3001, create an admin account, add your first monitor. Five minutes after pulling the repo, you are receiving alerts.

Three production hardening steps you should not skip:

1. SSL reverse proxy. Put Nginx or Caddy in front of port 3001 to encrypt dashboard access. Your monitoring interface contains a full map of your infrastructure — HTTPS is a prerequisite, not a nice-to-have.
2. 2FA. Enable two-factor authentication under Settings → Security. It is built-in, no plugin required.
3. Backups. v2.x removed the JSON export feature. Back up the Docker volume (/app/data) instead — a daily rsync to external storage does the job. Without backups, a SQLite corruption or an accidental volume removal wipes your entire monitoring configuration.

Uptime Kuma vs paid alternatives

The table below lines up the three options most teams evaluate in 2026.

Uptime Kuma wins on cost, channel count, and data sovereignty. Uptime Robot wins on zero-infra simplicity if you do not want to manage a container. Better Uptime wins on full incident management — on-call rotations, incident timelines, native runbook integration.

The most consequential difference is check location diversity: Uptime Robot and Better Uptime probe your services from multiple datacenters worldwide, which Uptime Kuma only does natively from the server it runs on. The Globalping integration in v2.1 partially closes this gap for public endpoints, but it does not replace a mesh of dedicated probes. If your monitoring server goes down, your monitoring goes down with it — that is the trade-off of a self-hosted tool.

What it does not do, and why that is fine

Uptime Kuma is an availability tool, not an observability platform. It answers « is my service up? » and « how fast? », not « why? ». It does not do metrics (CPU, memory, throughput), distributed tracing, or log analysis. For that, it lives alongside Prometheus + Grafana or SigNoz, not instead of them.

The typical small-team stack in 2026 looks like this:

• Uptime Kuma → external checks, public status page, multi-channel alerts.
• Prometheus + Grafana → internal metrics, performance dashboards, threshold-based alerting.
• Loki / SigNoz → centralized logs and tracing for debugging.

The two worlds complement each other. An Uptime Kuma alert says « the service is down »; Grafana tells you « RAM saturated four minutes before the outage. »

Verdict

Pick Uptime Kuma if you already run a VPS — even a modest 2 vCPU / 2 GB instance at $5/month — and you want unlimited monitors with no recurring subscription. Setup takes five minutes, the interface is clean enough for daily use, and the 90 notification channels cover every scenario from a Telegram ping to a PagerDuty trigger.

Stay on Uptime Robot (free tier) if you have fewer than 50 services and do not want to manage an extra container. The free plan handles a small fleet, and the built-in multi-location checks spare you from configuring Globalping.

Move to Better Uptime if you need full incident management — on-call rotations, timelines, runbook integration — and are willing to pay at least $24/month to avoid building those features yourself.

In every case, the question is no longer « which tool? » but « why did I not start yesterday? ». Monitoring that fits in 50 MB of RAM and costs nothing does not come around every day.

References

• Uptime Kuma — GitHub — official repository, stars, releases.
• Uptime Kuma — Official site — live demo, documentation.
• DevOps Pack — Uptime Kuma: Self-Hosted Monitoring That Actually Gets Used — May 2026.
• MakerStack — Uptime Kuma Review — March 2026.
• noted.lol — Uptime Kuma: Your Self-Hosted Uptime Monitoring Solution — September 2023, kept up to date.
• Uptime Robot — free tier, pricing.
• Better Uptime — pricing, features.