comparing self-hosted
Uptime Kuma vs Upptime: a server, or no server at all?
Both tools check that your site is up. They differ in one big way: do you want to run a server, or not? Uptime Kuma is a container with a database. Upptime runs on GitHub and needs no server. Everything else comes from that one difference.
the facts, side by side
| Uptime Kuma | Upptime | Uptimepage | |
|---|---|---|---|
| license | MIT | MIT code · ODbL data | AGPL-3.0 |
| configuration | UI only | one YAML file in git | UI + Terraform + REST + MCP |
| what you run | one container (Node) | no server, GitHub Actions | one binary + compose |
| hosted option | no | GitHub Pages, free | yes, free tier |
| check types | 31 incl. DBs · MQTT · browser | HTTP · tcp-ping | HTTP · TCP · DNS · TLS · ping · domain |
| fastest interval | 1s | 5 min, the Actions schedule | 60s free · 30s Pro · 10s self-hosted |
| probe locations | via Globalping add-on | GitHub runners, or Globalping | multi-region, or run your own |
| status page | yes, custom domains | GitHub Pages + custom domain | branded, own subdomain |
| page subscribers | RSS only | GitHub Issues + Slack | email · webhook |
| incidents | posted by hand | auto-opened as Issues | auto-opened from checks |
| history lives in | its database | the git repo | Postgres + ClickHouse |
| teams & roles | single login | GitHub repo permissions | orgs + roles |
| community (GitHub stars) | ~89k | ~17k | young |
Upptime's five-minute limit is what a GitHub Actions schedule allows. It is not a setting you can change.
Upptime checks are HTTP unless `check: tcp-ping` is set, which also covers Globalping locations.
Star counts rounded from GitHub, July 2026.
Verified July 2026 against both repositories. Refresh when a project releases a new version.
The main difference
Uptime Kuma is software you host yourself. You run one container with a database, then log in and add monitors in the dashboard. Upptime works the other way round. It uses only GitHub Actions, Issues and Pages, so there is no server to run and nothing to pay. GitHub Actions runs the checks on a schedule and saves response times to git. It opens an Issue when your site goes down and closes it when the site comes back. It also builds a status page on GitHub Pages. All the settings live in one file.
What Upptime does better
There is nothing to run. No container to update, no database to back up, and no bill if you already use GitHub. Every check result and every settings change is a git commit, so you get a full history for free. Incidents are normal GitHub Issues, so your team can assign them and discuss them in the same place, and Slack gets a message on each update. The code is MIT licensed. If your project already lives on GitHub, this takes very little work.
What Uptime Kuma does better
Speed and range. Upptime can check every five minutes at most, because that is the fastest a GitHub Actions schedule allows. Uptime Kuma 2.x checks every second. It supports 31 monitor types, including databases, MQTT, SNMP and a real Chromium browser check, and it sends alerts to 94 services. It also has the largest community of these tools, so someone has usually solved your problem already. If you need to know about downtime within one minute, Upptime cannot tell you.
The limits of both
Upptime keeps its data in the repository, so if you delete the repository the data goes too. Its checks run on GitHub's servers, not in a place you choose. Its status page shows what happened, but customers cannot subscribe to it. Uptime Kuma has different limits, and they come from how it is built. It has one shared login and no user roles. It has no official REST API to manage monitors, and no Terraform provider. And it checks from the server where you installed it, unless you add its Globalping monitor type, which borrows community-hosted probes you do not control.
Where Uptimepage fits
You may like Upptime because its settings live in version control, but five minutes is too slow for you. Or you may like Uptime Kuma's checks, but one login is not enough. Uptimepage sits between the two. It checks every 60 seconds over HTTP, TCP, DNS, TLS and ping. You can set it up in the UI, or declare it with the Terraform provider and REST API. It has organizations with user roles, and probes in several regions that you can also run yourself. Its status page is branded, and customers can subscribe by email or webhook. Incidents open on their own. It is one Rust binary. Host it free with no card, or self-host it under AGPL.