OmniFeed Search

Uptime Kuma

Self-hosted uptime monitor with a web dashboard, status pages and 90+ alert services

Visit github.com
Screenshot of Uptime Kuma
Uptime Kuma, from user-images.githubusercontent.com

Our verdict

#1 of 4 in Self-hosted uptime monitors · Best for most self-hosters

Pros

  • The widest choice of alert services of the four
  • One container with SQLite, set up from the browser
  • Two-factor login

Cons

  • The docs describe no supported API and no way to export monitors
  • No documented support for separate user accounts or roles

Who should skip:Teams that need separate logins with different permissions.

Read the full review →

Rankings and alternatives

Self-hosted uptime monitors scores

Evaluated Nov 7, 2026 Evidence ↓
  • Components to run 4

    4/5 means: One container with storage built in; installing without a container needs a separately installed language runtime or build tool

    One Docker container keeps its data in a mounted folder, with SQLite as a database option; installing without Docker needs Node.js 20.4 or newer.

  • What it can check 3

    3/5 means: Seven of the nine

    The feature list covers HTTP(S) keyword checks, TCP, ping, DNS records, push, and Docker containers, and certificate info is listed, which makes seven of the nine. Database queries and server CPU, memory and disk use are not in the documentation we found.

    Rests partly on what the sources don't mention, which is a weaker signal than what they say.

  • Fastest check interval 4

    4/5 means: 16 to 59 seconds

    The feature list gives 20-second intervals.

  • Alert channels 5

    5/5 means: 50 or more

    The README lists 90+ notification services.

  • Public status pages 4

    4/5 means: Four of the five

    Multiple status pages, a domain per status page, a pinned incident on a status page, and maintenance messages on status pages are documented; a way for visitors to subscribe is not.

  • Ways to manage monitors 1

    1/5 means: One of the five

    Monitors are managed in the web interface. The API it uses is described as internal and not officially supported for third-party integrations, and version 2 removed JSON backup and restore, leaving a copy of the data directory as the only backup method. No configuration file for monitors is documented.

  • Sign-in and users 3

    3/5 means: Two of the four

    A login and two-factor login are documented. Single sign-on isn't documented, and support for several admin users is the subject of a pull request rather than a documented feature.

  • Getting data out 4

    4/5 means: Three of the four

    A Prometheus endpoint with metrics for each monitor, SVG badges for public monitors, and API keys for the metrics endpoint that can't open the web interface. The status page data endpoint belongs to the internal API, which isn't officially supported for outside use, so it doesn't count.

  • Database choices 3

    3/5 means: A built-in database or one kind of database server

    The database type can be SQLite or MariaDB.

Evidence and sources

Self-hosted uptime monitors scores

Components to run 3 quotes
What it can check 2 quotes
Fastest check interval 1 quote
Alert channels 1 quote
  • “Notifications via Telegram, Discord, Gotify, Slack, Pushover, Email (SMTP), and 90+ notification services”
    github.com/louislam/uptime-kuma · checked
Public status pages 4 quotes
Ways to manage monitors 4 quotes
Sign-in and users 3 quotes
Getting data out 5 quotes
Database choices 1 quote

Facts

License 1 quote
Runs on 3 quotes
Needs 1 quote

Notability

Users 1 quote

Other quotes

Not cited by a score or fact 5 quotes