A hosted status page sounds cheap until you read the fine print. Statuspage starts around the price of a decent dinner per month and climbs fast once you want more than a handful of subscribers. Better Stack and Instatus are friendlier, but you’re still renting something you could run on a $5 VPS. So a lot of us end up here: I want a public “are we up?” page plus uptime monitoring, and I’d rather host it myself.
The good news is that the self-hosted options in 2026 are genuinely good. The annoying news is that they’re good at different things, and the popular advice (“just use Uptime Kuma”) is right maybe 70% of the time and wrong in ways that bite you six months in. Let me walk through the four tools actually worth your time — Uptime Kuma, Gatus, Statping-ng, and OpenStatus — and where each one falls apart.
What you’re actually choosing between
Before the tool-by-tool stuff, it helps to see the real axes of the decision. They’re not “which has more features.” They’re:
- Click-to-add vs config-as-code. Do you add monitors in a web UI, or do you write YAML and commit it to git?
- Single-location vs multi-region probing. Are you checking from one box, or from many places around the world so you can tell “the site is down” from “the site is down from Frankfurt”?
- Infra footprint. One Docker container you forget about, or a small stack with a database and external dependencies?
Almost every disagreement about these tools traces back to one of those three. Keep them in mind.
Uptime Kuma: the default, and usually the right one
Uptime Kuma is the 800-pound gorilla here — somewhere north of 85,000 GitHub stars as of mid-2026, which is absurd for a self-hosted monitoring tool. That popularity is earned. You run one Docker container, open the web UI, click “Add Monitor,” and you’re watching an endpoint in about ninety seconds. It does HTTP, TCP, DNS, ping, Docker containers, MQTT, gRPC, and keyword checks, with something like 90+ notification integrations baked in — Slack, Telegram, Discord, PagerDuty, generic webhooks, the works.
The public status page is built in, looks clean out of the box, and supports incident posts and maintenance windows. For most teams that just want a page customers can check and a Slack ping when checkout goes down, this is the whole job, done.
Here’s where it bites. Uptime Kuma checks from wherever it runs — one location. There’s no native multi-region probing, so if you host it in us-east and your European users can’t reach the app, Uptime Kuma cheerfully reports green. The other rough edge is that its data and config live in a SQLite database the app manages for you, not in a file you version-control. That’s fine until you want to recreate your whole setup on a new host or review monitor changes in a pull request. You can back up the volume, but you can’t really diff it.
So: best UI, biggest community, fastest to a working page. Single point of observation, and config you can’t put in git. For a homelab or a small SaaS with users in one region, none of that matters. For a globally-distributed app, it’s a real limitation.
Gatus: monitoring as a config file, and a little bit of a different philosophy
Gatus comes at the problem from the opposite direction. There is no UI for adding monitors. You write a YAML file, list your endpoints and the conditions they must pass, commit it, and Gatus reads it. That’s the entire model.
If you just recoiled, Gatus probably isn’t for you. If you instead thought “oh good, my monitoring lives next to my Terraform” — welcome, this is your tool. It’s a single Go binary, sips memory (people run it monitoring dozens of endpoints in well under 50MB of RAM), and the condition system is the nicest of the bunch. You’re not limited to “did it return 200.” You can assert on response time, on a JSONPath expression pulled out of the body, on TLS certificate expiry, on DNS resolution results. Something like [STATUS] == 200 and [RESPONSE_TIME] < 300 and [BODY].status == "healthy", all on one check.
The tradeoffs are the obvious mirror of Uptime Kuma’s. The status page is functional but plainer, and the whole thing leans toward “for engineers” — there’s no friendly dashboard for a non-technical teammate to add a monitor. It also runs from one location by default, same blind spot as Kuma, though because config is just text you can stand up several Gatus instances in different regions and aggregate, if you’re willing to do that plumbing yourself.
I reach for Gatus on projects that already live in GitOps. When every other piece of infra is a reviewed commit, having monitors be a clicky out-of-band thing in some web UI feels wrong, and Gatus fixes exactly that itch.
Statping-ng: the survivor with the nicest graphs
Statping-ng is the community continuation of the original Statping, which stopped getting updates years ago. The “-ng” fork picked it up as a drop-in replacement and has kept it alive, though at a much calmer pace than the others — roughly 2,000 stars and slower, steadier releases rather than a firehose of commits.
What it gives you that the others don’t lean into is presentation. Statping-ng’s status pages and historical graphs are genuinely pretty, it has a real database backend (SQLite, MySQL, or Postgres), and it exposes a service-status API plus its own notifiers. If your priority is a polished public-facing page with good-looking uptime history and you don’t need cutting-edge features, it holds up fine.
I’ll be honest about the catch, because it’s the whole story with this one: development velocity. When a tool’s main selling point is “it’s the maintained version of an abandoned project,” you’re betting on the maintainers sticking around. That bet has paid off so far, but it’s a different risk profile than a project getting dozens of PRs a week. I’d only pick Statping-ng today if its UI specifically wins me over against Uptime Kuma’s — and for most people, Kuma’s is now at least as good while moving much faster. It’s not a bad tool. It’s just rarely the best answer in 2026.
OpenStatus: the one that actually solves multi-region
OpenStatus is the newest of the four and the most ambitious. Instead of running probes from one box, it’s built edge-native — checks run across Cloudflare’s network, and it monitors from something like 28 regions in parallel rather than the round-robin handful you get from some hosted tools. That’s the single feature none of the other three give you natively, and for anyone serving a global audience it’s the whole reason OpenStatus exists. It pairs HTTP, TCP, and DNS monitoring with incident management and a public status page, the same scope as Instatus or Better Stack, but open source.
It’s also the one with caveats you have to read carefully. The hosted version at openstatus.dev is the path of least resistance. Self-hosting OpenStatus is real but more involved than docker run: the architecture leans on Cloudflare Workers, so a full self-host means a Cloudflare account and some Workers setup, not just a container on your VPS. There’s a small Docker image for running private probe locations, but the mental model is “distributed system on the edge,” not “single binary I scp to a box.” Licensing has also shifted around as the project matured (it’s currently AGPL-style copyleft), so if you care about license terms for embedding it somewhere, check the repo rather than trusting a blog — including this one.
The pitch I’d make: if multi-region monitoring is the actual requirement, OpenStatus is the only one of the four that ships it, and even paying for their hosted tier can come out cheaper than running a separate monitor plus a separate status page elsewhere. If multi-region isn’t a requirement, OpenStatus is more moving parts than you need.
The comparison, side by side
| Uptime Kuma | Gatus | Statping-ng | OpenStatus | |
|---|---|---|---|---|
| Setup | One Docker container, click to add | YAML config, single Go binary | Docker + DB backend | Cloudflare Workers stack |
| Config style | Web UI (SQLite-backed) | Config-as-code (git-friendly) | Web UI + DB | Code/API or hosted UI |
| Multi-region | No (single location) | No (DIY multiple instances) | No | Yes — native, ~28 regions |
| Public status page | Built in, polished | Functional, plain | Built in, nicest graphs | Built in, modern |
| Notifications | 90+ integrations | Solid, fewer | Built-in notifiers | Modern integrations |
| Resource use | Light | Very light (~40MB RAM) | Moderate (needs DB) | Edge / external infra |
| Best for | Most self-hosters | GitOps shops | Pretty history pages | Global, multi-region apps |
If you want a one-liner per tool: Kuma for almost everyone, Gatus if your infra is already code, Statping-ng if its dashboard genuinely wins you over, OpenStatus if you truly need to watch from many places at once.
Pick by your situation, not by star count
A few concrete scenarios, because “it depends” is useless advice on its own.
Homelab or single-region side project. Uptime Kuma. Stop reading, go install it. The multi-region gap doesn’t exist for you, and the UI will save you hours over the next year.
A team that runs everything through pull requests. Gatus. The config-as-code model isn’t a quirk to tolerate, it’s the point, and it’ll feel native next to the rest of your repo. Pair it with a second instance in another region if you grow into needing that.
You need to know whether you’re down everywhere or just from one place. OpenStatus, full stop. The others will lie to you by omission here. Start on their hosted tier to learn the tool, then decide whether the self-host complexity is worth owning.
You mainly care that the public page looks great. Try Statping-ng and Uptime Kuma side by side for an afternoon and let your eyes decide. Both are fine; this is genuinely a taste call.
When to stop self-hosting
The uncomfortable part. Self-hosting a status page has a hidden cost that doesn’t show up until something breaks: the monitor that tells you your app is down is running on infrastructure that can also go down, ideally not the same infrastructure as the app. If your Uptime Kuma box and your app share a host or a provider, an outage can take out both — and now you have no page to point customers at during the exact moment you need one.
Hosted tools like Better Stack and Instatus exist partly to dodge that problem: their monitoring lives somewhere your outage can’t reach. The break-even is roughly this — if you’re spending more than an hour a month babysitting your self-hosted monitor, or you’ve ever had it go dark with your app, the $10–20/month for a hosted plan is cheaper than your time and a lot less embarrassing. Self-host the monitoring for everything internal where you control the trade-off. Think hard before self-hosting the public status page for a product where downtime costs you customers.
Start with Uptime Kuma on a box that isn’t your app server, watch it for a month, and notice which of these limitations you actually hit. The one that annoys you first tells you which tool to switch to — and whether the answer was “self-hosted at all.”
Sources: Uptime Kuma on GitHub, Gatus vs Uptime Kuma comparison, OpenStatus on GitHub, How OpenStatus compares, Statping-ng on GitHub, Better Stack: Uptime Kuma alternatives