OpenStatus

Last reviewed Aug 26, 2026 · 763 words

OpenStatus is a hosted product first and a self-hostable codebase second, and that ordering matters more here than for most tools in this directory. The repository is a TypeScript monorepo whose web app expects a libSQL database, whose checkers were written as a separate service meant to run in many regions at once, and whose configuration assumes the company's own deployment. You can run it yourself in 256 MB, but you are assembling a platform rather than pulling one image. If the requirement is "a status page and a ping every minute", Uptime Kuma or Gatus will be finished before OpenStatus has cloned.

Three pieces that assume a cloud

The web app is the dashboard, the API and the public status pages. The checker is a separate service that actually performs HTTP and TCP probes, records latency, evaluates assertions and reports back. The database is libSQL, the SQLite fork behind Turso, which is trivial to run locally as a file but unusual enough that the ordinary "point it at Postgres" instinct does not apply. Scheduling of checks is wired for the hosted platform, and the self-hosting documentation is candid that the project is optimised for its cloud.

Running it yourself therefore means: a local libSQL server or file, the web app in Docker, at least one checker instance the web app can reach, and a scheduler to fire checks. It works, and the maintainers have been responsive to self-hosters, but expect to read the repository's self-hosting notes and a few issues rather than a one-page install. This is the "self-host setup is involved" line in the catalogue, spelled out.

What it gives you that Uptime Kuma does not

The monitoring itself is a generation newer than the classic self-hosted tools, and that is the reason to care.

The percentile charts are the killer feature for anyone who runs an API. "Up" is a low bar; knowing that the 95th percentile from Frankfurt doubled after a deploy is what catches regressions before users write in. Gatus gets close on the assertion and configuration-as-code side, and the Gatus versus Uptime Kuma comparison covers that split, but neither has regional latency as a first-class idea.

Multi-region needs multiple regions

Self-hosting from one house or one VPS collapses the main selling point to a single vantage point, and a single vantage point is exactly what Uptime Kuma already provides. To get the value, the checker has to run in 2 or 3 places: a cheap virtual server in Europe, one in North America, one in Asia, each reporting to the web app. That is 3 more boxes to keep patched, which is a real cost against a hosted free tier that at last check includes several monitors across the company's regions for nothing.

The status page must not share the outage

This trap predates OpenStatus but bites harder with a self-hosted monorepo. A status page hosted on the same server, network or ISP as the services it reports on goes down with them, at which point it reports nothing to anyone. Whatever you choose, put the public page somewhere independent, which the self-hosted status pages post argues is the single decision that matters more than the tool.

What I'd do

Split it. Use the hosted OpenStatus free tier for external, multi-region checks on the 3 or 4 endpoints the outside world depends on, which gets the percentile charts and an independently hosted status page without running the monorepo. Run Gatus or Uptime Kuma inside the network for the 40 internal services, where one vantage point is correct and the homelab monitoring pattern applies. Self-host OpenStatus itself only if you need latency-by-region data you cannot send to a third party and you are comfortable operating a libSQL database and a fleet of checkers; at that point you are a small monitoring company, and it will feel like one. It is a good replacement for Pingdom either way, just not always a self-hosted one.