Uptime Kuma Review

Uptime Kuma monitors HTTP(S), keyword, JSON query, TCP, WebSocket, ping, DNS records, push (heartbeat) checks, Steam game servers, and Docker containers, and OpenAlternative adds gRPC, databases, and certificate expiry checks. It sends notifications through Telegram, Discord, Gotify, Slack, Pushover, SMTP email, PagerDuty, webhooks, and 90+ other services. It provides multiple status pages with domain mapping and branding, ping charts, certificate info, proxy support, maintenance windows, two-factor authentication, multi-user access, and many interface languages. Heartbeat monitors let cron jobs and background tasks check in. The wiki also documents status badges, resetting a password through the CLI, a Prometheus integration with API keys (so you can scrape Uptime Kuma's own metrics), systemd and OpenRC service files, and a reverse-proxy setup with a Cloudflare Tunnel.

With Docker you run a command that publishes port 3001 and mounts a volume at /app/data (using the louislam/uptime-kuma:2 image), or download compose.yaml and run docker compose up -d, binding the port to 127.0.0.1 for local-only access. Without Docker you need Node.js 20.4 or later and Git, clone the repository, run npm run setup, and start with node server/server.js, using PM2 for background operation. Because Uptime Kuma uses WebSockets, a reverse proxy must pass the Upgrade and Connection headers. The wiki warns that SQLite can corrupt where file locking is unreliable, such as on some NFS setups, so map /app/data to a local directory or volume, and network file systems are not supported. The official install describes only SQLite (MariaDB appears only in an unofficial Helm chart description). Supported platforms are major Linux distributions and Windows 10 (x64) or Windows Server 2012 R2 (x64) and later, while FreeBSD, OpenBSD, NetBSD, Replit, and Heroku are not supported. The wiki has pages for environment variables, Docker tags, updating, and a migration guide from v1 to v2, and the README states no RAM requirements.

After first launch you create an admin account, add monitors with an interval and notification targets, and build a status page by selecting monitors and mapping a domain. The dashboard shows live status, response-time charts, and certificate information, and maintenance windows pause alerts during planned work. This section reflects the README and wiki; we did not run an instance.

• Monitor types including HTTP(S), TCP, DNS, ping, WebSocket, Docker, keyword, JSON query, and push heartbeats
• 90+ notification integrations
• Public or private status pages with custom domains, branding, and badges
• Certificate expiry info and maintenance windows
• Prometheus integration, systemd and OpenRC service files, and a CLI password reset
• Two-factor authentication and multi-user support

• Dead simple to deploy: one container, SQLite, and a clean interface
• MIT license and a huge community, with about 92,000 stars
• Very broad notification coverage, so alerts fit existing tools
• Free status pages with custom domains, and a Prometheus endpoint for your own dashboards

• It checks from the machine where it runs, with no built-in distributed probing from multiple global locations, so a failure of your own network can hide or fake outages
• Network file systems are not supported for storage, and SQLite can corrupt on unreliable file locking
• Reverse proxies must be configured for WebSockets, which is a common stumbling block
• Several platforms (FreeBSD, Replit, Heroku) are unsupported, and the official install covers only SQLite
• No incident-management or on-call scheduling like commercial suites, and you must monitor the monitor

Uptime Kuma is free under the MIT license, and your only cost is hosting. The OpenAlternative page also lists an affiliate VPS offer, which is not Uptime Kuma pricing.

UptimeRobot, Better Stack, Checkly, and Cronitor are hosted monitoring services that probe from multiple regions and offer on-call and incident features. Uptime Kuma gives you comparable check types and status pages on your own server without per-monitor fees, but it checks from one place and does not manage incidents. For a small team or homelab, it covers most needs, and a hosted service remains better when you need geographic coverage or an independent vantage point. A common pattern is to run Uptime Kuma for internal and detailed checks and a free hosted probe to watch Uptime Kuma itself.

• Developers and homelab users who want monitoring and a status page for free
• Small teams that already run Docker
• Anyone who wants heartbeat monitoring for cron jobs

• Teams that need multi-region probing from independent locations
• Organizations that need on-call scheduling and incident workflows
• Setups that must store data on network file systems