Uptime Kuma

Open-source uptime monitoring, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

• What it is: Open-source (MIT) uptime monitoring tool — think UptimeRobot, but the data stays on your server, the checks run at 20-second intervals, and the vendor can never raise your bill [5].
• Who it’s for: Developers, homelab enthusiasts, and small teams who want instant alerts when something goes down, without paying per-monitor SaaS pricing or sending their infrastructure topology to a third party [1][5].
• Cost savings: UptimeRobot’s paid plans start at $8/mo (Solo) and reach $64/mo (Enterprise). Uptime Kuma runs on a $2–6/mo VPS with no monitor limits, no check-interval restrictions, and no per-notification fees [5].
• Key strength: Genuinely zero-config setup — Docker one-liner, running in under five minutes. 84,193 GitHub stars. Supports 90+ notification channels. Checks as fast as every 20 seconds [README][5].
• Key weakness: Single-location monitoring. If your monitoring server shares infrastructure with what it’s monitoring, it goes blind exactly when you need it most. Not a bug — it’s the architectural reality of any single-instance self-hosted monitor [2].

---

What is Uptime Kuma

Uptime Kuma is a self-hosted monitoring dashboard built in Node.js. You point it at your websites, APIs, TCP services, DNS records, Docker containers, or anything that responds to a ping, and it tells you when they stop responding — via Telegram, Slack, Discord, email, PagerDuty, or 86 other notification services.

The project describes itself as “a fancy self-hosted monitoring tool” in the GitHub README and “a self-hosted monitoring tool” on the homepage, which is as understated as it gets for something with 84,193 stars. The creator, Louis Lam, built it in 2021 out of frustration with overcomplicated alternatives. The pitch isn’t complicated: UptimeRobot but self-hosted, with a cleaner interface and no artificial limits on check frequency or monitor count [README][1].

What separates it from the “enterprise monsters that require a expertise to configure” (Nagios, Zabbix) isn’t raw capability — it’s the five-minute path from zero to working dashboard [1]. The interface is reactive and modern rather than the 2008 admin-panel aesthetic that most open-source monitoring tools still ship with.

---

Why people choose it

The reviews converge on a consistent picture: Uptime Kuma wins on simplicity, cost, and privacy. The criticism is focused and honest: it’s structurally limited by being a single-location monitor.

Versus UptimeRobot and Pingdom. The case is straightforward. UptimeRobot’s free tier restricts you to 50 monitors with 5-minute check intervals. Their paid Solo plan at $8/mo gives you 1-minute intervals and 50 monitors. Uptime Kuma self-hosted has no monitor limit and supports 20-second intervals at a total monthly cost of your VPS bill [5][README]. One MassiveGRID article [5] points out that SaaS tools also expose your infrastructure topology — every endpoint you monitor, your response times, your availability patterns — to a third party. Self-hosting keeps that data inside your own network.

Versus Nagios and Zabbix. Patryk Tokarski [1] spent a paragraph on this: Nagios and Zabbix are powerful, but they require weeks of configuration file spelunking to get running. Uptime Kuma is documented well enough that a non-operations person can set it up. The trade-off is depth — Uptime Kuma won’t give you CPU graphs, memory trending, or SNMP traps. It tells you if something is up or down.

The single-location problem — and why it matters. Pavel Lazureykis [2] wrote the most useful critical piece on Uptime Kuma, and it’s worth taking seriously. The argument: self-hosted monitoring from one location is testing your network path, not your customers’ paths. When your datacenter provider has a network incident, your Uptime Kuma instance and your application go down simultaneously. The monitor goes blind at the exact moment you need it. He documents the alert fatigue cycle: false positives from your monitor’s ISP having issues train your team to ignore alerts — until the real outage happens and nobody responds [2].

His proposed fix (“run three Uptime Kuma instances in different regions”) creates a new problem: three databases, three configurations, three notification rule sets, no consensus mechanism between them. He’s right that this is an architectural limitation, not a fixable bug. Uptime Kuma is honest about what it is: reliable monitoring from a single location. That’s appropriate for a homelab, a small development team, or a situation where you have a separate monitoring server in a different datacenter or on a different provider. It’s less appropriate for production infrastructure where you need multi-region visibility [2][5].

The MassiveGRID deployment guide [5] addresses this directly: “Best practice: Host your monitoring on a separate server from the services being monitored.” Separate provider, not just separate droplet.

---

Features

Based on the README and first-hand article descriptions:

Monitor types:

• HTTP(S) — standard URL availability checks
• HTTP(S) Keyword — check that a specific string appears in the response body
• HTTP(S) JSON Query — validate a specific value in a JSON response
• TCP port monitoring — verify that a service port is open and accepting connections [5]
• Ping/ICMP — network device availability
• DNS record monitoring — verify DNS resolution returns expected values
• WebSocket — connectivity checks for WebSocket endpoints
• Docker container monitoring — check container status via the Docker socket [README][5]
• Push / Heartbeat — your application sends a ping to Uptime Kuma; if it stops, you get alerted. Useful for cron jobs and intranet devices [1][4]
• Steam game server monitoring
• MQTT

Notifications:

• 90+ services including Telegram, Discord, Slack, Gotify, Pushover, Email (SMTP), PagerDuty, webhooks, ntfy [README][5]
• Patryk Tokarski [1] runs a heartbeat setup where a Raspberry Pi pings a VPS every 60 seconds; after 3 missed heartbeats (3 minutes), Telegram fires

Status pages:

• Multiple status pages, each mappable to a custom domain [README]
• Public or password-protected, shareable with users or clients [5]
• Maintenance windows — schedule planned downtime so monitors pause during maintenance [5]

Other:

• 20-second minimum check interval (most SaaS tools limit free/lower tiers to 1-5 minutes) [README][5]
• SSL/TLS certificate expiry monitoring with alerts at 30, 14, and 7 days before expiration [4]
• Ping/response time charts with historical data [3][5]
• Proxy support [README]
• 2FA support [README]
• Multi-language interface [README]
• REST API [features list]

---

Pricing: SaaS vs self-hosted math

UptimeRobot (primary SaaS competitor):

• Free: 50 monitors, 5-minute check intervals
• Solo: $8/mo — 1-minute intervals, 50 monitors
• Team: $34/mo — 1-minute intervals, 100 monitors
• Enterprise: $64/mo — 30-second intervals, 200 monitors [merged profile]

Uptime Kuma self-hosted:

• Software license: $0 (MIT) [README]
• VPS to run it on: $2–6/mo — MassiveGRID cites a “Cloud VPS starting at $1.99/mo” as sufficient for monitoring hundreds of endpoints [5]
• Patryk Tokarski [1] runs his instance on a 256MB RAM VPS for under $5/mo, noting it uses ~170MB RAM total and “CPU usage is practically zero”

Managed Uptime Kuma (if you don’t want to self-host):

• Elestio’s fully managed Uptime Kuma starts at $14/mo, including automated backups, SSL, updates, and monitoring [4]

Concrete savings math:

A small team running 100 monitors with 1-minute check intervals: UptimeRobot Team at $34/mo versus Uptime Kuma on a $6 VPS with no monitor limit and 20-second intervals. That’s $28/mo saved, $336/year — with better check frequency, not worse. Over three years: $1,000+ saved.

For a homelab user with 10–20 monitors: the Free UptimeRobot tier might cover you. The argument for Uptime Kuma isn’t always cost at this scale — it’s data privacy, no check-interval restrictions, and the ability to monitor internal network devices that external SaaS tools can never reach [2][5].

---

Deployment reality check

The installation reality matches the marketing: straightforward. The Docker one-liner from the README (docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2) is production-ready as-is for single-user setups. Docker Compose is one curl command to fetch the compose file and one docker compose up -d [README].

Patryk Tokarski [1] claims “you can have it running and monitoring your services in under 10 minutes.” MassiveGRID [5] says Coolify’s one-click catalog gets you to a working dashboard “in under five minutes.” Neither is exaggerating for a technical user.

What you actually need:

• A Linux VPS with 256MB–512MB RAM (Tokarski’s setup uses 170MB total [1])
• Docker installed
• A domain and reverse proxy (nginx or Caddy) if you want HTTPS for the dashboard — not required for internal monitoring
• Optional: Docker socket volume-mounted if you want to monitor Docker containers

What can go sideways:

The biggest deployment mistake, documented explicitly by MassiveGRID [5] and Lazureykis [2]: hosting Uptime Kuma on the same server, same provider, or same datacenter as the services you’re monitoring. When there’s a provider-level incident, everything goes dark simultaneously. Use a different VPS provider, or at minimum a different datacenter region.

NFS storage is explicitly unsupported — the README includes a warning to map to a local directory or volume, not a network file system.

Non-Docker installation (Node.js + PM2) is documented but adds more moving parts. For anyone deploying this seriously, the Docker path is the right one.

For non-technical users: the UI itself is accessible, but getting a Linux VPS, installing Docker, setting up a reverse proxy, and pointing a domain takes real time. Realistically 1–3 hours with a guide, more if you’re new to Linux servers.

---

Pros and Cons

Pros

• MIT license, no restrictions. Self-host, fork, embed, or redistribute without contacting a lawyer [README].
• Runs on minimal hardware. 170MB RAM on a 256MB VPS at near-zero CPU. This matters — you can bolt monitoring onto the smallest instance in your stack without it competing for resources [1].
• 20-second check intervals with no paywalls. UptimeRobot charges $64/mo for 30-second intervals and caps you at 200 monitors. Uptime Kuma imposes neither limit [README][5].
• 90+ notification channels. Covers every alerting pipeline a small team would realistically use. The Telegram heartbeat setup is particularly elegant for homelab use cases [1][README].
• Internal network monitoring. External SaaS tools can’t reach your private IPs, localhost services, or intranet devices. Self-hosted monitoring can [5][2].
• Status pages included. Public-facing status pages with custom domain support, no separate tool needed [README][5].
• Certificate expiry alerts. 30/14/7-day warnings before SSL certs expire [4].
• Push/heartbeat monitoring. Cron jobs and background tasks can ping Uptime Kuma; if they stop pinging, you get alerted. Useful beyond basic URL monitoring [1][4].
• Clean UI. Multiple reviewers specifically praise the interface as modern and readable [1][3][5].

Cons

• Single-location monitoring is architecturally limited. Your monitor can only see your network path. Regional outages, CDN routing issues, and ISP-specific problems are invisible unless your monitor is in the affected region [2]. This is a design reality, not a fixable bug.
• Co-hosted monitoring defeats itself. Most people deploy Uptime Kuma on existing infrastructure. When that infrastructure has an incident, the monitor and the monitored service go dark together [2]. Requires discipline to deploy correctly.
• False positives cause alert fatigue. If your monitoring server’s ISP hiccups, everything appears down. After a few false alarms, teams start adding “verification delays” — and then miss the real outage [2].
• No multi-region consensus. Running multiple instances doesn’t solve the geography problem cleanly. Three instances give you three opinions with no voting mechanism [2].
• Not for infrastructure metrics. CPU, memory, disk, network throughput — Uptime Kuma doesn’t do any of that. It tells you if something is up or down, not why it’s slow [1].
• Single maintainer dependency. The project is primarily maintained by Louis Lam. No governance model is visible beyond individual sponsorship [README].

---

Who should use this / who shouldn’t

Use Uptime Kuma if:

• You’re running a homelab, personal servers, or a small team’s infrastructure and want instant alerts without paying UptimeRobot’s recurring fees.
• You need to monitor internal network devices — printers, NAS, local APIs — that external SaaS tools can never reach.
• You want 20-second check intervals without paying enterprise-tier SaaS pricing.
• You care about keeping your infrastructure topology private (endpoint list, response times, availability patterns).
• You’re comfortable with Docker or willing to spend an afternoon learning it.

Use it with eyes open if:

• You’re monitoring customer-facing production services. Uptime Kuma should be deployed on a separate provider from what it’s monitoring. Budget for the second VPS.
• You’re a non-technical founder. The tool itself is approachable, but the Linux + Docker + reverse proxy path requires either technical help or a managed option like Elestio ($14/mo) [4].

Skip it (consider a SaaS tool) if:

• You need multi-region monitoring with consensus logic out of the box.
• You need incident management, on-call scheduling, escalation policies — look at Pagerduty, Better Uptime, or Grafana OnCall.
• You need infrastructure metrics (CPU, memory, disk) alongside uptime — Grafana + Prometheus is the right stack.
• The command line is a hard blocker and you don’t have technical help available.

Skip it (use UptimeRobot free tier) if:

• You have fewer than 50 monitors and 5-minute check intervals are acceptable. The math doesn’t favor self-hosting at that scale.

---

Alternatives worth considering

• UptimeRobot — the primary SaaS competitor. Free tier covers 50 monitors at 5-minute intervals. Cheaper than most alternatives at low scale, more expensive at high scale, fully managed [merged profile].
• Grafana + Prometheus — the right answer if you need infrastructure metrics alongside uptime. Significantly more complex to set up. Use it when you need to know why something is slow, not just that it’s down.
• Gatus — newer, YAML-configured, designed for teams that prefer config-as-code over a web UI. Less polish, more composable.
• Freshping — SaaS, free tier includes 50 checks at 1-minute intervals from multiple locations. Solves the single-location problem that Uptime Kuma doesn’t, at the cost of data privacy and vendor dependency.
• Betterstack (formerly Better Uptime) — SaaS with multi-region checks, incident timelines, on-call scheduling. Appropriate when monitoring complexity grows beyond what a single dashboard can handle.
• Nagios / Zabbix / Icinga — legacy open-source monitoring. Powerful, complex, well-suited for enterprises with dedicated ops teams. Wrong tool for anyone who wants to be running in under an hour [1].
• Healthchecks.io — specialized for cron job and heartbeat monitoring specifically, open source, also self-hostable.

The practical shortlist for most small teams is Uptime Kuma vs UptimeRobot. Use Uptime Kuma if you want data privacy, internal network monitoring, and no artificial limits. Use UptimeRobot if you want external multi-location checks with zero setup.

---

Bottom line

Uptime Kuma does exactly one thing and does it well: it tells you when something stops responding, quickly, across a wide range of monitor types, through whatever notification channel you already use. The 84,193 GitHub stars are a realistic signal — this isn’t a niche power-user tool, it’s something people recommend to their non-technical friends. The setup is genuinely five minutes for anyone who’s touched Docker before.

The limitation is real and worth stating plainly: a single-location self-hosted monitor has a structural blind spot. When your provider has an incident, the monitor and the monitored service fail together. Deploy it on a separate provider, not just a separate server, and you’ve mitigated most of that risk. The remaining gap — multi-region visibility — is a problem you don’t have until you’re operating at a scale where it matters.

For a founder or small team currently paying UptimeRobot $34–64/mo, or living with UptimeRobot’s free-tier check-interval restrictions: the math is obvious. A $3 VPS and 20 minutes of setup eliminates a recurring SaaS bill and removes the check-frequency ceiling.

If the setup is the blocker, upready.dev deploys this for clients as a one-time service. You get the infrastructure, you own it.

---

Sources

1. Patryk Tokarski, Data Engineering Toolkit — “Uptime Kuma: The Monitoring Tool That Actually Makes Sense” (Aug 11, 2025). https://dataengineeringtoolkit.substack.com/p/uptime-kuma-the-monitoring-tool-that
2. Pavel Lazureykis, Medium / Code Matters — “Your Uptime Monitoring Is Broken By Design” (Sep 20, 2025). https://codematters.medium.com/your-uptime-monitoring-is-broken-by-design-1312c511093f
3. WinPoin — “Uptime Kuma – Salah Satu Aplikasi Monitoring Andalan Saya”. https://winpoin.com/uptime-kuma-salah-satu-aplikasi-monitoring-andalan-saya/
4. Elestio — “Managed Uptime-kuma as a Service”. https://elest.io/open-source/uptime-kuma
5. MassiveGRID Blog — “How to Self-Host Uptime Kuma with Coolify (Server Monitoring on Your Infrastructure)” (Feb 26, 2026). https://www.massivegrid.com/blog/self-host-uptime-kuma-coolify/

Primary sources:

• GitHub repository and README: https://github.com/louislam/uptime-kuma (84,193 stars, MIT license)
• Official website: https://uptime.kuma.pet
• Notification services list: https://github.com/louislam/uptime-kuma/tree/master/src/components/notifications