Uptime Kuma vs Gatus vs OpenStatus: the self-hosted status page comparison, measured (2026)

Quick answer (2026)

If you want a status page running tonight and you do not want to think about it again, run Uptime Kuma. It is MIT, it is one container, and it is the only one of the three that publishes real versioned Docker tags you can pin and roll back.

If your monitors belong in git next to your Terraform, run Gatus. One Go binary, one YAML file, Apache-2.0. Accept in exchange that it moves slowly, and read below for what "slowly" actually measured.

If you want the polished multi-region product and you are genuinely willing to run a build pipeline, OpenStatus is the most ambitious of the three. Before you commit, know that it has never cut a version in its life, and that its documented self-host path compiles six services on your machine.

Five things we found on August 23, 2026 that the first page of Google does not say.

OpenStatus has never published a release. Zero git tags. Zero GitHub releases. Not one, in the three years since the repository was created in June 2023. Its container images do exist, on GitHub Container Registry, and they are tagged by seven-character commit SHA plus moving latest and main tags. So you can pin a self-hosted OpenStatus, but you pin it to a commit, and there is no changelog between two commits because there are no releases to write one against. To find out what changed between 443bb37 and 5d150aa you read the git log.

The OpenStatus Quick Start builds from source, and the faster path is undocumented. The docker-compose.yaml in the repository root carries a build: stanza for all six OpenStatus services. Those image: openstatus/server:latest lines are local build tags, not registry pulls, which is why searching Docker Hub for them finds nothing. There is a second file, docker-compose.github-packages.yaml, that pulls prebuilt images from ghcr.io instead. That is the file most people actually want. DOCKER.md never mentions it: we grepped the document for ghcr, github-packages, prebuilt and pull and got zero hits.

Uptime Kuma shipped three releases in two and a half hours, and if you use Docker none of it touched you. On August 22, 2026, 2.5.1 landed at 06:50 UTC, 2.5.2 at 08:44, 2.5.3 at 09:20. That reads like a fire. Read the release notes and it is milder than it looks: 2.5.2 fixed a broken non-Docker installation introduced by 2.5.1, and 2.5.3 fixed a release tagged with the wrong version number. The container path, which is the documented default, was never the thing that broke. It is a bad afternoon for people running from source and a non-event for everyone else.

Gatus has not cut a release in three months, and that is not the same as abandoned. The last tag, v5.36.0, is dated May 19, 2026. Between that tag and August 23, 2026 the repository took exactly twelve commits, and most of them are documentation and dependency bumps. But the release those twelve commits sit on top of shipped a PostgreSQL indexing change its own notes describe as roughly a fifteen times performance improvement. This is a mature project in a low-throughput maintenance groove, not a dead one. Whether that is reassuring or alarming depends entirely on whether you need a feature it does not already have.

The throughput gap between the three is enormous, and it is not the gap the star counts suggest. Over the same window, May 19 to August 23, 2026: OpenStatus took 304 commits, Uptime Kuma 160, Gatus 12. Uptime Kuma has 90,507 stars to OpenStatus's 9,005, a ten to one ratio, and yet OpenStatus is committing at nearly twice the rate. Stars measure how many people once thought a thing was neat. They do not measure whether anyone is still writing it.

What we measured, and how

Everything above came from live state on August 23, 2026, not from other people's articles. Specifically: the GitHub repositories API for stars, licence, creation date and push time; the releases API for tag history and release notes; the commits API paginated to exhaustion for commit counts over a fixed window; the Docker Hub v2 tags API and the GHCR token-and-tags endpoints for what is actually published and under what tag scheme; and the raw docker-compose.yaml, docker-compose.github-packages.yaml and DOCKER.md files from each repository's default branch.

We did that because the pairwise comparisons that currently rank all describe features. Features are the part of this decision that is easy to look up and rarely the part that hurts. What hurts eighteen months in is a tool you cannot pin, a build you cannot reproduce, or a maintainer cadence you misread.

Uptime Kuma

Uptime Kuma is a Node application, MIT licensed, 90,507 stars as of August 23, 2026. You run one container and click things.

The operational story is the best of the three and it is not close. Docker Hub carries 393 tags for louislam/uptime-kuma, including precise ones like 2.5.3 and 2.5.3-slim, floating majors like 2, and channels like next and nightly2. That means you can pin an exact build, you can roll back to a known-good one, and you can decide independently whether you want the slim image. This sounds obvious. It is the single largest practical difference in this comparison.

Its release stream is also where the feature velocity is. Version 2.5.1 alone added seven new notification providers, contributed by seven different people, including regional SMS gateways for Israel and the Maldives. That is what a large contributor base buys you: not architectural elegance, but the specific integration you need already existing because somebody in your situation wrote it.

What you give up is configuration as code. Uptime Kuma stores its monitors in its own database and expects you to manage them through the UI. If your instinct is to review a monitor change in a pull request, you will be fighting it the entire time.

Gatus

Gatus is a single Go binary, Apache-2.0, 11,885 stars, and it is the oldest of the three by four years. Created September 2019.

The whole product is one YAML file. You declare endpoints and you declare conditions against them, in the shape [STATUS] == 200 or [RESPONSE_TIME] < 500. It probes over HTTP, TCP, ICMP, DNS, gRPC and SSH. There is no database of monitors to back up, because the monitors are the config file, and the config file is in your repository.

That single design decision is the entire case for Gatus. A monitor change becomes a diff. A code review catches it. A rollback is a git revert. If your infrastructure already lives in version control, Gatus is the only one of the three that fits without argument.

The honest cost is cadence. Twelve commits in three months is thin, and if you file a feature request you should not expect it soon. It is worth being precise about what that risk actually is, though. Gatus is not a hosted service that can disappear and it is not a company that can pivot. It is an Apache-2.0 Go binary that already does the thing. The failure mode of a slow open-source project is that it stays exactly as useful as it is today, which for a status page is a much smaller problem than it would be for, say, an error monitoring stack that has to keep up with new runtimes and new SDK versions.

OpenStatus

OpenStatus is the newest, the fastest moving, and the one that requires the most reading before you commit. TypeScript, AGPL-3.0, 9,005 stars, created June 2023.

It is also the only one of the three that is a commercial product with an open-source core. The hosted plans are Starter at $30 a month, Pro at $100 and Scale at $500, with two months free on annual billing, and a free tier of one monitor and one status page with three components at a minimum ten minute check interval (openstatus.dev/pricing, August 2026). The pricing page does not mention self-hosting anywhere, which tells you where self-hosting sits in the company's priorities. That is not a criticism. It is a fact you should price in.

Architecturally it is a Bun and Next.js monorepo orchestrated with Turbo. The compose stack is six OpenStatus services plus libSQL for the database and a local Tinybird instance for analytics. Compare that to Gatus's one binary. You are not choosing a status page here, you are choosing to operate a small distributed system, and you want somewhere sensible to put it.

What you get for that is the most capable product of the three. Multi-region checks, a private-location agent so you can probe things inside your own network, API monitoring as code, and a genuinely good-looking public status page.

Two cautions, both verified rather than inferred. First, the versioning situation above: no tags, no releases, SHA-pinned images. Second, the licence. AGPL-3.0 is a network copyleft licence. For running a status page for your own product it is almost certainly irrelevant to you. If you were thinking of embedding OpenStatus into something you sell, stop and read the licence properly, because that is exactly the case AGPL is written to cover, and it is the one axis on which the other two are unambiguously more permissive.

The licence axis, briefly

All three are genuinely open source by the OSI definition. None of them is a source-available licence with a rug-pull clause, which is worth saying out loud in 2026 given how many infrastructure projects have relicensed. The difference here is only about what happens if you redistribute or offer the software itself as a service.

So which one

Run Uptime Kuma if the honest answer to "who maintains this" is "me, occasionally". It is one container, it pins properly, it rolls back, and the notification integration you need probably already exists.

Run Gatus if your monitors should be reviewable. It is the only one where a monitoring change goes through the same process as a code change, and the slow release cadence is a much smaller risk for a mature single-binary tool than it would be for a fast-moving platform.

Run OpenStatus if you need multi-region or private-location probing and you have the appetite to operate six services, build them yourself or pin them by commit SHA, and re-read the AGPL. If you want what OpenStatus does but not what it costs to run, their hosted tier is the honest comparison, and at $30 a month it is cheaper than most people's time.

What none of these three replaces is alerting on the inside of your application. A status page tells you and your customers that an endpoint answered. It does not tell you that a background job has been silently failing for six hours while the endpoint kept returning 200. Those are different problems and you want both.