cloudparts

Uptime Kuma

A self-hosted uptime monitor in one Node.js container: HTTP, TCP, ping, DNS, database and browser checks as often as every 20 seconds, 90+ notification services and public status pages, all set up in a web UI.

What it is
Synthetic monitoring
Type
Open source
Made by
Louis Lam and contributors
License
MIT
Facts checked
23 October 2026
Website Source code

What it is

Uptime Kuma is a self-hosted alternative to hosted uptime services such as UptimeRobot. You run one Docker container (or a Node.js process), open port 3001, create the admin account, and add monitors in the browser. Each monitor checks one thing on an interval of 20 seconds or more: an HTTP(S) URL with an expected status, keyword or JSON query result, a TCP port, ping, a DNS record, a Docker container, or a database or broker such as PostgreSQL, MySQL, SQL Server, MongoDB, Redis, MQTT, RabbitMQ or Kafka. A “real browser” monitor loads the page in Chromium through Playwright, and a push monitor turns the check around: a cron job or backup script calls a URL, and Kuma raises the alarm when the calls stop.

When a check fails (after optional retries), Kuma notifies through more than 90 services, among them email, Slack, Telegram, Discord, Microsoft Teams, PagerDuty and webhooks. It serves any number of public status pages, each mappable to its own domain, plus status badges, and exposes a /metrics endpoint that Prometheus can scrape. Everything lives in one data directory: SQLite by default, or MariaDB since version 2.0 (October 2025). The browser talks to the server over a Socket.IO WebSocket rather than a REST API, so a reverse proxy has to pass WebSocket upgrades through.

Why teams pick it

  • Up in one docker run, with every setting in a web UI; no config files or query language to learn
  • Broad check types for one tool: HTTP with keyword and JSON assertions, TCP, ping, DNS, Docker, databases, message brokers, game servers and a real browser
  • More than 90 notification integrations and any number of public status pages, free
  • MIT licensed and very widely used, with frequent releases

Watch out for

  • Checks run from wherever you host it, usually one place, so a network problem there looks like an outage and it can’t see regional failures; host it outside the system it watches
  • One admin account: there are no users, roles or teams, a request open since 2021
  • No supported API for creating monitors: the Socket.IO and REST endpoints are internal and may change between versions, so monitors can’t easily be kept in code
  • SQLite needs local storage with POSIX file locks, so NFS mounts are not supported, and SQLite data can’t be moved to MariaDB directly

Alternatives

What all synthetic monitoring have in common →Compare side by side →
ChecklyCommercialHosted synthetic monitoring written as code: API checks, uptime monitors and Playwright browser tests defined in TypeScript next to your app, tested with a CLI and deployed to run from 22 locations.

How it fits with other technologies

Run it, then let a cron job report in with a push monitor · bash

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

# Open http://localhost:3001, create the admin account, add a Push monitor,
# then call its URL at the end of the job; silence for too long raises an alert
./nightly-backup.sh && curl -fsS "https://kuma.example.com/api/push/$PUSH_TOKEN?status=up&msg=OK"

See it in a real stack

No architecture uses Uptime Kuma yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2021–2026

Louis Lam wanted a self-hosted monitor like UptimeRobot and found little to choose from: the closest, Statping, was unstable and no longer maintained. He started Uptime Kuma on GitHub in July 2021, partly to learn Vue 3 and Vite and to try a single-page app that talks over WebSocket instead of a REST API, and released 1.0 that month.

The project grew quickly, passing 90,000 GitHub stars by 2026, with notification providers, monitor types and translations arriving mostly as community pull requests. Lam still maintains it, funded by GitHub Sponsors and Open Collective.

Version 2.0, in beta from October 2024 and released in October 2025, added MariaDB as an alternative to SQLite, rootless Docker images and SNMP and RabbitMQ monitors, rewrote how heartbeats are aggregated (upgrades migrate the table on first start, which can take hours), and dropped the JSON backup feature, Alpine images and Node.js versions before 20.4.

Why it’s built this way

Socket.IO instead of a REST API
The UI updates live as heartbeats arrive, and Lam wanted to try a WebSocket-driven single-page app. The cost is that there is no stable public API for automation.
SQLite in one data folder
One container and one volume keep self-hosting simple and backups a matter of copying a directory. MariaDB came in 2.0 for larger installs.
Configuration in the web UI, not files
The goal was a monitor anyone could set up in minutes, in the spirit of hosted services like UptimeRobot, rather than a YAML-driven tool.

Timeline

  1. 2021

    First commit in July; 1.0.0 released on 11 July

  2. 2024

    2.0.0-beta.0: MariaDB support, rootless images, SNMP and RabbitMQ monitors

  3. 2025

    2.0.0 released in October, with a heartbeat table migration and Node.js 20.4 minimum

  4. 2026

    2.5.x releases continue; 2.5.6 in October

Sources9 · facts checked 23 October 2026

Improve this page on GitHub