Uptime Kuma: setup, limits and alternatives

Uptime Kuma is the most popular self-hosted uptime monitor. This guide covers what it does, how to run it, where self-hosting stops, and how it compares with the alternatives, our own hosted service among them.

Set it up ↓ How it compares
Written by Uptimia

What Uptime Kuma is

Uptime Kuma is a self-hosted monitoring tool under the MIT license. You run it on your own machine, your checks and history stay on that machine, and no plan tier decides what you may monitor. The project sits above ninety thousand stars on GitHub, which makes it the default answer when someone asks what to self-host for uptime checks.

Out of the box it checks HTTP and HTTPS (plain, keyword and JSON query), raw TCP, ping, DNS records, WebSocket connections, Steam game servers and Docker containers, and its push monitors catch things that report in rather than answer, like cron jobs. Alerts reach more than ninety notification services, from email and Slack to Telegram and webhooks, and it serves multiple status pages that can sit on their own domains.

Running it in one command

The Docker route is the whole quick start. A volume keeps your data across updates.

On any machine with Docker, this starts Uptime Kuma on port 3001 with its data in a named volume:

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

Without Docker it runs on Node.js 20.4 or newer. Two habits save self-hosters grief: put it behind a reverse proxy with authentication instead of exposing the port raw, and treat updates as routine, because security fixes arrive only if you install them.

What people monitor with it

The homelab is the natural habitat, and the push monitor is the underrated feature.

The classic fleet is a homelab: Home Assistant, Pi-hole, Plex, TrueNAS, the UniFi controller, and the websites running beside them. HTTP checks cover the web interfaces, ping and TCP cover the boxes and services, and a DNS check watches the resolver itself.

Push monitors reverse the direction: something inside your network calls a URL on schedule, and silence raises the alert. That covers cron jobs and backups, and it also answers a common question, how to monitor your own internet connection: a device inside pings a push monitor hosted outside, and the gaps in the record are your outages. The same technique works against a hosted heartbeat check, which keeps the record outside the connection it measures. Heartbeat monitoring →

Where self-hosting stops

None of this is a flaw in Uptime Kuma. It is the shape of running the watcher yourself.

One vantage point

Your install checks from where it runs. A hiccup on its own network reads as everything down, and an outage visible only from outside your network reads as everything fine. Hosted services answer this by re-checking from several regions and alerting only on agreement; a lone instance cannot.

How confirmation works →

The watcher shares your fate

When the machine running Uptime Kuma goes down, monitoring goes down with it, and no alert marks the difference. Self-hosters solve this with a second instance elsewhere or an outside check pointed at the first one.

Upkeep is yours

Updates, backups of the data volume, and the reverse proxy in front are your responsibility. The time cost is modest for one instance and real for several.

Uptime Kuma against the field

One line each, for the comparisons people actually search.

config as code

Gatus

monitoring as YAML in git instead of clicks in a dashboard; the same self-host trade with a code-review workflow.

runs on GitHub

Upptime

no server at all; GitHub Actions checks every five minutes with the status page on GitHub Pages.

metrics stack

Prometheus + blackbox

uptime probes inside a metrics stack; the right call when Prometheus already runs, heavy when it does not.

the platform

Zabbix

a whole infrastructure-monitoring platform; website checks are one feature among hundreds, and the learning curve matches.

the fleet

Checkmk

fleet and server monitoring first, HTTP checks second; closer to finished than most self-hosted options.

inside view

Netdata

per-second metrics from inside the server; a different job that pairs with Kuma rather than replacing it.

cron jobs

Healthchecks

cron and scheduled-job monitoring specifically; narrower on purpose.

dashboards

Grafana

draws dashboards from data someone else collects; it needs a prober like blackbox, it is not one itself.

all in one

OneUptime

the whole category, status pages to on-call, in one self-hosted platform, with the operational weight that implies.

The full roundup, every figure sourced and dated: open-source website monitoring tools →
Leaving Kuma in either direction: Uptime Kuma alternatives compared →

Uptime Kuma or Uptimia

The real comparison is self-hosted against hosted. Both answers are legitimate; they fit different situations.

What Uptime Kuma gives you

No subscription, data on your own machine, checks against things only your network can see, and a tool you can read the source of. The price is the three limits above: one vantage point, shared fate, and upkeep.

What a hosted service gives you

Checks from many regions with an outage confirmed before anyone is alerted, nothing to patch or back up, and alerting that does not depend on your own machine being up. Uptimia adds the check types self-hosting rarely covers: browser transactions, real-user timings, and a server agent feeding the same dashboard.

The two also stack: keep a Kuma instance for the inside view and point one hosted uptime check at it, so the watcher is watched. The free plan covers that. Push-style jobs can report to a hosted heartbeat the same way they report to a Kuma push monitor.

What the hosted side looks like while an outage is confirmed: three regions agree before anyone is alerted, which is the view no single instance has.

The outside view,handled for you.

Keep your Kuma. Add one hosted check from many regions, confirmed before it alerts, free for one monitor.

Start your free 30-day trial →
30 days free no credit card cancel anytime

Uptime Kuma, defined

Uptime Kuma is an open-source, self-hosted monitoring tool released under the MIT license. It checks websites and services over HTTP, TCP, ping and DNS among others, sends alerts through more than ninety notification services, and publishes status pages. It runs from a single Docker container or on Node.js, and it is maintained as a community project on GitHub.

01Is Uptime Kuma free?+
Yes. The software is open source under the MIT license, with every feature included. What you pay is the machine it runs on and the time to keep it updated and backed up.
02Is Uptime Kuma safe to use?+
The code is public and widely reviewed, and your monitoring data never leaves your machine. Safety in practice depends on how you run it: keep it updated, and put it behind a reverse proxy with authentication rather than exposing the port to the internet.
03What can Uptime Kuma monitor?+
HTTP and HTTPS with keyword and JSON-query matching, raw TCP ports, ping, DNS records, WebSocket connections, Steam game servers and Docker containers, plus push monitors for anything that can call a URL on a schedule.
04Does Uptime Kuma need Docker?+
No. Docker is the one-command route, and a plain install needs Node.js 20.4 or newer. Most self-hosters use the container because updates and data live in one tidy place.
05How do I monitor my internet connection with it?+
Reverse the check. A device inside your network calls a push monitor on a schedule; when your connection drops, the calls stop arriving and the gap is recorded. The push monitor must live outside the connection being measured, on a machine elsewhere or on a hosted heartbeat check. Heartbeat checks →
06Can it monitor a Windows service?+
Its monitor types do not list Windows services. The usual route is indirect: a scheduled task on the Windows machine reports to a push monitor, and the service check lives inside that task.
07Why am I seeing false positives?+
A single instance checks from one place, so any hiccup between it and the target reads as downtime. Raising retries helps. The structural fix is agreement between several vantage points, which is how hosted services suppress false alarms. How confirmation works →
08How many monitors can one install handle?+
The project publishes no number, and the practical ceiling depends on the host and the intervals you set. Keep intervals modest as the list grows, and watch the machine's own load, because the monitor competes with whatever else it runs beside.
09Uptime Kuma or UptimeRobot?+
Self-hosted against hosted free tier. UptimeRobot's free plan checks fifty monitors from its own infrastructure with email alerts; Kuma gives you every feature on your own machine with the three self-hosting limits above. People who want neither trade move to a paid hosted plan. Free uptime monitoring compared →
10Does Uptime Kuma have status pages?+
Yes. It serves multiple status pages, each mappable to its own domain, with customisation that goes as far as custom CSS.

Self-hosted inside, hosted outside

Run Uptime Kuma for the view from within. Add one Uptimia monitor for the view your users have, confirmed from many regions before it alerts.

Start free trial →
30-day free trial Free plan: one monitor, five-minute checks Heartbeat checks for push-style jobs No credit card
The free plan needs no card and does not expire.