Uptime Kuma: A Self-Hosted Monitor That Puts Status Pages and Alerts on Your Own Hardware

Why You Would Self-Host a Monitor

Uptime Kuma solves a specific problem: you want to know when your website or service is down, and you want to publish that status to the public, without sending your data to a third-party monitoring service. The README is explicit about the motivation. The author wanted a self-hosted tool like Uptime Robot but found options like statping unstable or abandoned. So Uptime Kuma is built for people who already run servers and prefer to keep monitoring inside their own infrastructure. It is not for someone who wants a zero-maintenance SaaS dashboard. You pay for the self-hosting with your own time and hardware. The audience is a developer or a small operations team that runs a few services and wants a clean, reactive interface to track uptime, plus the ability to customize alerts and status pages.

What It Actually Checks

The feature list is broad. Uptime Kuma can monitor HTTP(S) endpoints, TCP ports, HTTP keyword presence, HTTP JSON query, WebSocket connections, ping, DNS records, push-based checks, Steam game servers, and Docker containers. That is a wide net. For a typical user, the HTTP and ping checks will cover most needs. The keyword check is useful for verifying that a page returns expected content, not just a 200 status. The JSON query check lets you validate a field in a JSON response, which is handy for APIs. The push check is interesting: you can have a client send a heartbeat to Uptime Kuma, and if the heartbeat stops, it alerts. That is a different model from polling and is useful for cron jobs or background workers. The Docker container check means you can monitor the health of containers on the same host, which is a nice touch for a self-hosted setup. The documentation does not go deep on each check type, so you may need to experiment with the UI to see the exact options.

How the Data Flows and Where It Lives

Uptime Kuma runs as a Node.js server that performs the checks at a fixed interval. The README mentions a 20-second interval, which is the minimum polling frequency. That is a real constraint: you cannot get sub-20-second checks. The server stores its data in a directory called /app/data in the Docker image. The README warns that NFS filesystems are not supported, and you should map to a local directory or volume. That is a hard limitation. If you try to run it on a network share, you risk data corruption or performance issues. The architecture is a single-server model. There is no mention of distributed probes or multiple check locations. So if you need to monitor from different geographic regions, this is not the tool. The UI is built with Vue 3 and Bootstrap 5, and the author notes they used WebSocket with a single-page app instead of a REST API. That means the dashboard updates in real time without page reloads, which is a nice experience. The data is stored locally, so you have full control, but you also have to back it up yourself.

Getting It Running: Docker and Bare Metal

Installation is straightforward. The README gives a Docker Compose method: create a directory, download a compose.yaml from the repository, and run docker compose up -d. That brings it up on port 3001. There is also a plain Docker command: docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2. That command maps a named volume to /app/data, which is the correct way to persist data. If you want to expose it only to localhost, you change the port binding to 127.0.0.1:3001:3001. For non-Docker installs, you need Node.js 20.4 or higher, Git, and PM2. The setup is git clone, npm run setup, then either node server/server.js for a try or pm2 start server/server.js --name uptime-kuma for background running. PM2 also gives you monitoring with pm2 monit and startup integration with pm2 startup && pm2 save. The README lists supported platforms: major Linux distros, Windows 10 x64, and Windows Server 2012 R2 or higher. FreeBSD, OpenBSD, and NetBSD are not supported, nor are Replit or Heroku. That is a clear boundary.

Alerts and Status Pages: The Payoff

The main reason to use Uptime Kuma is the notification and status page features. Notifications go to Telegram, Discord, Gotify, Slack, Pushover, email via SMTP, and 90-plus other services. The README links to a directory of notification components, so the list is long. That breadth means you can integrate with whatever chat or ticketing system you already use. Status pages can be multiple, and you can map them to specific domains. That is useful if you run several products and want separate public status pages. The ping chart and certificate info are extra touches. Certificate info is practical: you can see when an SSL certificate expires, which helps avoid outages from expired certs. The UI is described as fancy, reactive, and fast, and the author explicitly wanted a nice UI. That matters because a monitoring tool you check daily should not be painful to look at. The demo server is temporary and wipes data after 10 minutes, so you can try the interface before committing.

Where It Falls Short: Storage, Interval, and Single-Node Limits

The most concrete limitation is the NFS warning. The README says file systems like NFS are not supported, and you must map to a local directory or volume. If you run a NAS or shared storage setup, that is a dealbreaker. The 20-second interval is another boundary. For services that need faster detection, such as a payment gateway, 20 seconds may be too slow. The README does not mention any way to configure a shorter interval. The single-server model is also a restriction. There is no mention of running multiple check locations, so you cannot get an outside perspective on your own services. That is a common feature in hosted monitors, and its absence is notable. Also, the documentation is thin on some check types. You get a feature list, but not detailed configuration examples for each. You will have to explore the UI to understand options like the JSON query syntax. Finally, the project is actively developed, with releases on the same day, but that means updates come frequently and you need to follow the update guide. The README points to a wiki page for updates, so the process is documented, but it is still your responsibility.

Alternatives: What Else Is Out There

The README names Uptime Robot as the hosted alternative that inspired this project. Uptime Robot is a SaaS service that monitors your endpoints from multiple global locations, which solves the single-node problem. It also offers sub-minute intervals on paid plans. The trade-off is that you do not control the data or the infrastructure. Another alternative is Statping, which the README mentions as unstable and no longer maintained. So if you want a self-hosted tool with an active community, Uptime Kuma is a stronger choice than Statping. There is also the broader category of full monitoring suites like Prometheus and Grafana, but those are more complex and not directly comparable. Uptime Kuma is a focused tool: it does uptime checks, alerts, and status pages. If you need metrics and long-term trends, you would pair Uptime Kuma with something else. For a simple, self-hosted uptime monitor, Uptime Kuma is a direct replacement for a hosted service, with the caveat that you lose multi-region checks.

Maintenance and License: What You Sign Up For

Uptime Kuma is licensed under the MIT license, which is permissive. You can use, modify, and redistribute it, including in commercial products, as long as you preserve the copyright notice. That is a low-friction license for adoption. The project is written in JavaScript, so you need a Node.js runtime. The README specifies Node.js 20.4 or higher for non-Docker installs. That is a concrete requirement. Maintenance cost is moderate. You have to handle updates yourself. The README links to a wiki page for updating, and the release cadence is active, with multiple releases on the same day in the recent history. That suggests frequent bug fixes and features, but also a need to keep up with changes. The data directory is your responsibility to back up. If you use Docker, you manage the volume. The project has a sponsorship model, but the README does not indicate any paid tiers or features. So the cost is purely operational: server resources, storage, and your time for upgrades and backups. The documentation is clear about what is supported, which helps you plan.

Editorial conclusion

Adopt Uptime Kuma if you want a self-hosted monitor with a polished UI, broad notification support, and status pages without paying a SaaS subscription. Avoid it if you cannot run persistent local storage or need to monitor from multiple regions, since it is designed for a single server and NFS is explicitly unsupported. Before deploying, verify your Node.js version (20.4 or higher) and confirm your target platform is not FreeBSD, OpenBSD, or NetBSD. Also test the 20-second minimum interval against your endpoints, because that cadence may be too slow for critical services. The project is actively maintained, with frequent releases, but you own the upgrade path and the data. If you need distributed probes or sub-minute checks, look elsewhere; if not, Uptime Kuma is a solid, MIT-licensed foundation.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes