nomadLab

Search nomadLab

Infrastructure7 min read

Self-Hosted Status Pages: Check the Commit Log First

One of these four has shipped nothing in fourteen months. Another closed multi-region monitoring as not planned. A third dropped its Cloudflare requirement and is now a docker compose file. The comparison tables have not caught up.

Updated

A public “are we up” page plus uptime monitoring is a small enough job that self-hosting it makes sense, and there are four tools people keep recommending for it. The recommendations are mostly repeating each other from 2024, and three of the four have moved since.

So before any feature table, the check that decides the most: what has each project shipped lately. All figures below came from the GitHub API and each project’s own repository on 23 August 2026.

LicenseStarsLatest releaseCommits since 23 May
Uptime KumaMIT90,4842.5.3, 22 Aug 2026100+
GatusApache 2.011,882v5.36.0, 19 May 202610
OpenStatusAGPL 3.09,005untagged, pushed 21 Aug 2026100+
Statping-ngGPL 3.01,988v0.93.0, 4 Jun 20250

That last row is the finding. Statping-ng was the community continuation of an abandoned project, and the pitch for it was always “the maintained fork.” Its last release was fourteen months ago, its last commit to the default branch was the same day, and nothing has landed in the three months I looked at. Whatever it is now, it is not the maintained fork. I would not put a public status page on it, and the rest of this piece treats the choice as three-way.

A two-axis chart. The vertical axis runs from one probe location at the bottom to 28 regions at the top. The horizontal axis runs from configuration held in a UI and a database on the left to configuration held in a file you commit on the right. Uptime Kuma and Statping-ng sit at the bottom left, Gatus at the bottom right, and OpenStatus alone at the top right. Where the check runs from, and where the config lives 28 regions one location OpenStatus Gatus Uptime Kuma Statping-ng, dormant config in a UI and a database config in a file you commit Gatus can aggregate several instances, but that feature is still marked experimental.
Two axes, because almost every disagreement about these tools is really about one of them.

Uptime Kuma: the default, and it will not probe from two places

Uptime Kuma is where most people should start and where most people should stay. One container, a web UI, a monitor watching an endpoint ninety seconds later, and a status page that looks fine without configuration. Version 2.0 shipped in October 2025 and the project has been releasing steadily since; 2.5.3 landed the day before I wrote this.

The limitation everyone mentions is that it checks from wherever it runs. What is worth knowing is that this is a decision rather than a gap: the multi-region feature request was closed as not planned in August 2024. If you are waiting for it, stop waiting. One Uptime Kuma is one vantage point, and two Uptime Kumas are two dashboards.

The other constraint is the one that shows up later. Monitors live in a SQLite database the app manages, so your monitoring configuration is not a file, cannot be reviewed in a pull request, and cannot be recreated on a new host except by copying the volume.

Gatus: the config file is the product

Gatus has no UI for adding monitors, which is the entire point. You write YAML, commit it, and the binary reads it. The condition language is the best of the group and it goes well past checking for a 200:

endpoints:
  - name: api
    url: "https://api.example.com/health"
    interval: 60s
    conditions:
      - "[STATUS] == 200"
      - "[RESPONSE_TIME] < 300"
      - "[BODY].status == UP"

Response time, a JSONPath expression pulled out of the body, TLS expiry, DNS results, all asserted in the same block. For a team whose infrastructure is already reviewed commits, having monitors be a clicky thing in a web UI feels wrong, and this is the tool that fixes it.

Gatus does have an answer for watching from more than one place, and it is more honest to describe it as partial. The remote instances feature pulls endpoint statuses from other Gatus instances into one dashboard, and the documentation says plainly that it “is an experimental feature. It may be removed or updated in a breaking manner at any time,” with known issues. It solves the display problem, not the alerting problem, and you would still be running and upgrading N instances.

The pace is the thing to weigh. Ten commits in three months and a release three months old is a healthy small project rather than a stalled one, but it is a different velocity from Uptime Kuma’s, and worth knowing before you build on it.

OpenStatus: the multi-region one, and the self-host story changed

OpenStatus is the only one of the four that probes from many places natively: 28 global regions across three cloud providers, checking in parallel rather than round-robin. If your actual question is “are we down, or are we down from Frankfurt,” this is the only answer on the list.

The advice that has aged badly is about self-hosting it. Older comparisons, including the earlier version of this page, describe OpenStatus as a Cloudflare Workers stack that you cannot really run on your own box. The repository’s own instructions are now cp .env.docker.example .env.docker followed by docker compose up -d, with prebuilt images published under ghcr.io/openstatushq/ for the server, dashboard, workflows, status page, checker, and private locations. Private probe locations are an 8.5MB image. That is a normal self-host.

Two things to check before adopting it. The license is AGPL 3.0, which matters if you intend to embed it in something you distribute. And the project does not cut tagged GitHub releases, so “which version am I running” is an image digest rather than a version number, which is a real operational difference from the other two.

It also undercuts the neat split the comparison tables draw. OpenStatus ships monitoring as code through YAML, a CLI, and a Terraform provider, so config-as-code is no longer the thing that distinguishes Gatus.

Pick by the two axes, not the star count

If you serve one region and want a page today, Uptime Kuma. The gap you are accepting is one vantage point and config you cannot diff, and for a homelab or a single-region product neither one will bother you.

If your infrastructure is already pull requests, Gatus. The condition language is worth the missing UI, and if you later want a second location, plan on running a second instance and treating the aggregation as a dashboard convenience rather than a guarantee.

If “down from where” is a question you actually have to answer, OpenStatus, and the self-host is now a compose file rather than a project.

The thing that outlives all three choices is where you run it. A monitor that shares a host, a region, or a provider with the thing it monitors will go dark at exactly the moment you need a page to point customers at. Put it somewhere else, and if the only somewhere else you have is the same account as production, that is the argument for paying someone $10 a month rather than an argument for a different tool.

Keep reading