Agentless uptime checks set up in a web UI
Uptime Kuma is a self-hosted monitoring tool under the MIT license, written in JavaScript with a Node.js server and a Vue 3 front end. Monitors are added in the web UI, each with a target and a check interval that defaults to 60 seconds; below 20 seconds, the UI warns that performance may suffer. When a target stops responding, the instance sends an alert, and the same monitors feed the public status pages it serves itself.
Checks run from the instance or from the Globalping probe network, so nothing gets installed on the monitored machines. Checkmate goes the other way, with an agent that reports CPU, memory and disk usage from each server.
The comparison of self-hosted uptime monitors and status pages sets Uptime Kuma against tools that declare their checks in YAML or install an agent on servers.
Cron heartbeats, database checks and 90+ notifiers
- Well beyond HTTP: HTTP(s) with keyword or JSON query assertions, TCP, ping, DNS, gRPC, MQTT, Kafka, SNMP, SMTP and Docker containers, plus PostgreSQL, MySQL/MariaDB, SQL Server, Oracle, MongoDB and Redis.
- Passive monitors: a Push monitor hands out a URL for a script or cron job to call on every run. When no call arrives within the expected window, the monitor goes down.
- 90+ notification services, according to the README, among them Telegram, Discord, Slack, Gotify, Pushover and email.
- Detailed status pages: an overall status banner, then monitors in collapsible groups, each showing a bar of recent checks and its 24-hour uptime. Incidents are written in Markdown and kept in a history since 2.1.0, maintenance notices appear on the page, and an RSS feed is available. Each page can have its own domain and custom CSS.
- Maintenance windows: one-off, recurring or cron-based. They mute notifications for the affected monitors and show up on the status pages.
- Prometheus metrics on
/metrics, per monitor, behind an API key or the account credentials.
Single instance, single admin, no PostgreSQL
A self-hosted Uptime Robot. The README says so in its motivation section: the author wanted something like Uptime Robot that could be self-hosted, and found Statping, one of the closest options, unstable and no longer maintained.
One instance, no high availability. Asked about running several replicas on a shared MariaDB database, a repository collaborator answered "We are not a distributed system" (#6394, November 2025), then wrote in July 2026 that high availability is not planned (#84). The same collaborator advises against putting a status page on the same infrastructure, datacenter or credit card as the services it reports on.
SQLite for small setups, MariaDB for more. On first start, v2 asks which database to use: SQLite, which the setup screen recommends "for small-scale deployments", MariaDB embedded in the full Docker image, or an external MariaDB/MySQL server. PostgreSQL is not an option (a request has been open since September 2026, #7908), and there is no official path from an existing SQLite database to MariaDB.
Docker or Node.js, on a local disk. The project documents the louislam/uptime-kuma:2 image and a Node.js 20.4 install under pm2; the one Helm chart listed for Kubernetes is unofficial. NFS is not supported because SQLite needs POSIX file locks, and copying the data directory is the only supported backup.
No subscriptions on status pages. Email sign-up for visitors has been requested since November 2021 (#916) and is still open; the RSS feed is what they get. Cachet handles email subscribers and asks to be hosted apart from the service it reports on.
Everything lives in the web UI, under one account. Uptime Kuma reads no configuration file (requested since November 2021, #956), and the Socket.io API behind the UI is documented as internal, with no stability guarantee. Gatus instead declares its monitoring in YAML that can be versioned with the code. Setup creates a single admin account; multi-user support has been requested since July 2021 (#128).
The Docker monitor hands over the host. It goes through the Docker socket, which controls the whole daemon, and in that case the wiki advises against exposing the instance to the Internet, yet that instance is the one serving the public status pages.
v2 stable since October 2025, v3 in the works. 2.0.0 shipped on October 20, 2025 after a year of betas, 2.5.5 on September 16, 2026, and the main branch already carries version 3.0.0-beta.0 with no release yet. The Docker latest tag is deprecated and still points to v1, so the tag to follow is 2.