Open source uptime monitors and status pages, tested
Monitors and status pages you can run yourself. The list is ordered by whether each project came up when Argusic installed it fresh, with the recording of that attempt one click away.
Tested between and . Each row shows its own test date; a project can change after that day.
15 of 15 tested projects run. 1 more waiting for a test.
In short: 13 of the 15 tested projects started as-is on a fresh machine: gatus, hertzbeat, kener, tinystatus, Uptimer, PongHub, upstat, and peekaping, and 5 more. 2 more started once a stand-in replaced a service they expect, such as a database: tianji and UptimeKit-CLI.
Measured by Argusic on a fresh machine every time. Every number links to its evidence.
| # | project | verdict | Argusic Score | language | stars | tested on |
|---|---|---|---|---|---|---|
| 1 | gatus | Runs | 100 / 100 | Go | 12,266 | |
Automated developer-oriented status page with alerting and incident support What the test found: Gatus builds from source, launches on port 8080, serves the health API returning 200, monitors all configured HTTP and DNS endpoints, and 74 of 76 Go test packages pass with only ICMP tests failing due to missing CAP_NET_RAW in the unprivileged container. 6 minutes. | ||||||
| 2 | hertzbeat | Runs | 100 / 100 | Java | 7,417 | |
An AI-powered next-generation open source real-time observability system. What the test found: HertzBeat server builds, its full Maven test suite passes except one Docker-only integration test, and the assembled server runs with working JWT login and authenticated API on port 1157 in this container. 37 minutes. | ||||||
| 3 | kener | Runs | 100 / 100 | TypeScript | 5,195 | |
Stunning status pages, batteries included! What the test found: Kener v4.1.3 is built, serves a status page on port 3000 with SQLite and Redis, all 136 tests pass, health endpoint confirms database and Redis connectivity. 14 minutes. | ||||||
| 4 | tinystatus | Runs | 100 / 100 | Python | 1,592 | |
Tiny status page generated by a Python script What the test found: TinyStatus installs and runs cleanly out of the box: all 17 unit tests pass, and the app generates a valid status page with proper HTTP/ping/port check results, incident rendering, and history tracking. 2 minutes. | ||||||
| 5 | Uptimer | Runs | 100 / 100 | TypeScript | 481 | |
A Powerful Serverless Uptime Monitoring & Status Page on Cloudflare's Edge Network What the test found: Uptimer project installs, builds, passes all 488 unit tests across 50 test files, typechecks, lints, and runs locally with the worker API responding with correct data on public and authenticated admin endpoints. 10 minutes. | ||||||
| 6 | PongHub | Runs | 100 / 100 | Go | 225 | |
Free endpoint monitoring. One-click deployment. What the test found: PongHub builds, all 4 test packages pass, and the binary runs end-to-end against a real HTTP endpoint, correctly logging success and generating the HTML report. 4 minutes. | ||||||
| 7 | upstat | Runs | 100 / 100 | TypeScript | 200 | |
🟢 a simple open-source, self-hosted status monitoring tool What the test found: Upstat Go API builds and runs on port 8000 with SQLite, accepting user signup/signin, creating and listing monitors with heartbeat pings, and serving Swagger docs over HTTP. 17 minutes. | ||||||
| 8 | peekaping | Runs | 96 / 100 | Go | 1,202 | |
Open Source Uptime Kuma Alternative What the test found: Peekaping API server starts on port 8034 with SQLite, connects to local Redis, and responds HTTP 200 on /api/v1/health. All 16 Go test packages pass. The React web frontend builds without errors. 16 minutes. | ||||||
| 9 | statuspage | Runs | 96 / 100 | JavaScript | 770 | |
A simple, zero-dependency, pure js/html status page based on GitHub Pages and Actions. What the test found: Health check script curls 5 URLs and logs results; static server serves index.html, JS, CSS, SVG, config, and 5 log files with 200 status. 3 minutes. | ||||||
| 10 | issue-status | Runs | 96 / 100 | TypeScript | 427 | |
A flexible, modern and blazingly fast ☄️ status page What the test found: The issue-status monorepo is fully functional: pnpm install succeeds, tests pass (1 passed, 1 skipped/todo), the issue-status package builds via Vite, both CLIs build via tsdown, the example status page app builds and serves correctly via dev/built modes, and the GitHub provider fetches real data from the public... 37 minutes. | ||||||
| 11 | server-status | Runs | 96 / 100 | PHP | 407 | |
Simple, modern looking server status page with administration and some nice features, that can run even on shared webhosting What the test found: PHP 8.3 and MariaDB 10.11 are running, the server_status database has 11 tables with proper settings, and all pages (index, admin, install, API) respond with HTTP 200 and render correct content without warnings. 27 minutes. | ||||||
| 12 | fettle | Runs | 91 / 100 | TypeScript | 280 | |
Free GitHub-powered beautiful status page utilizing GitHub Pages, Actions, and Issues for real-time updates and incident management. Make sure to share love by... What the test found: Fettle installs, builds, and exports cleanly (next.config.js patched for image optimization); the production server and the exported static site both serve HTTP 200, and a real headless-browser load of the exported page fetched live GitHub data and showed all systems operational with both services and incidents... 12 minutes. | ||||||
| 13 | uptime-kuma | Runs | 64 / 100 | JavaScript | 92,213 | |
A fancy self-hosted monitoring tool What the test found: Uptime Kuma 2.5.3 starts on Node.js 22, listens on port 3001, serves the setup page over HTTP, and passes 196 of 242 backend tests; 38 tests fail solely due to missing Docker and missing ping binary in the container sandbox. 10 minutes. | ||||||
| 14 | tianji | Runs with mocks | 92 / 100 | TypeScript | 3,103 | |
Tianji: Insight into everything, Website Analytics + Uptime Monitor + Server Status. not only another GA alternatives What the test found: Dependencies installed, project builds successfully, shared and most server unit tests pass, client component tests mostly pass; server cannot launch without a PostgreSQL database. 25 minutes. | ||||||
| 15 | UptimeKit-CLI | Runs with mocks | 92 / 100 | JavaScript | 277 | |
A modern, cross‑platform CLI to monitor websites and APIs. What the test found: The project builds, its 246-unit test suite passes 6/6 suites, and the CLI starts a background daemon, adds HTTP/DNS/SSL monitors, and renders a live TUI dashboard with real monitoring data (DNS resolution, SSL certificate validation, HTTP checks). The edit command was fixed to accept 0 retries. Node 22 is required. 18 minutes. | ||||||
| - | maintenant | Not yet tested | - | Go | 529 | - |
runs installed and started with its real dependencies. runs with mocks started after stand-ins replaced external services such as a database or a third-party API. could not verify neither the standard agent nor the stronger one got it running within the time limit; the log shows where it stopped.
Before you choose
Decide whether you want to run a database. Five projects started as-is with an embedded or SQLite store (gatus, PongHub, upstat, hertzbeat, and kener, which also brought up a real Redis); three expected a Redis, MySQL, or PostgreSQL that the agent had to stand in for (peekaping, server-status, tianji). The verdict column and the finding under each name tell you which group a project is in before you read its README.
Decide whether you need monitoring or only a status page. statuspage and fettle are static sites that publish a status you feed them; they cannot probe anything themselves. gatus, uptime-kuma, and peekaping run the checks and host the page. tianji goes further and bundles web analytics; it is also on the self-hosted analytics list, with its own rank there.
Look at the minutes. The time each verifying run took is a fair proxy for how much a first install asks of you: 7 to 12 minutes for the single-binary and static projects, 23 to 38 for the ones that build a full stack (hertzbeat, issue-status, server-status, upstat).
Read the finding before the star count. uptime-kuma has the most stars by far and still ranks twelfth, because on its test day it started only after a pre-built front end was downloaded and 46 of its 240 backend tests failed; the row says so, and the log shows it.
How we tested
For a monitor or status page, working meant the server process came up on the clean machine and answered over HTTP: the web UI or a health endpoint responded, and where the project ships a test suite, the suite ran.
Two things separated the verdicts on this list. Projects with a single binary or a bundled SQLite store started as-is; gatus, for example, went on to execute real HTTP and DNS checks against live endpoints. Projects that expect a database, a cache, or a message queue only started once the agent stood in for that service: peekaping needed an in-process Redis, server-status a local MySQL, and tianji a PostgreSQL built from extracted packages. Those are "runs with mocks".
Checks that need infrastructure a container does not provide, such as ICMP ping (raw sockets) or Docker, appear as failed tests in the log and did not block the verdict when the server itself was up; uptime-kuma is the clearest case. Static status pages were built and served locally; statuspage and fettle are examples.
On this list as of the latest test: 13 projects ran as-is, 2 with mocks, 0 could not be verified, 1 still waiting. Languages tested: Go, Java, JavaScript, PHP, Python, TypeScript. Every attempt used a clean single-use machine, the subject at a pinned version, and a 45-minute limit; the complete procedure is on the methodology page.
Frequently asked questions (FAQs)
What does "runs" mean for an uptime monitor?
The server started on a clean machine and answered over HTTP, with its test suite run where one exists. It does not mean every check type works: ping needs raw-socket rights a container lacks, and that shows up as failed tests in the log, not in the verdict.
Why is uptime-kuma not at the top?
Rank is measured, not editorial. On its test date the server started only after the agent downloaded a pre-built front end and patched a timeout shim, and the tests that need Docker or ping failed. That is "runs with mocks", which ranks below projects that started as-is. The log is one click away on its row.
Do these need a database to self-host?
It depends on the project. Several on this list ran on SQLite or with no database at all. The ones marked "runs with mocks" needed a service the agent had to stand in for, such as Redis, MySQL, or PostgreSQL; each project's page says which.
Are static status pages tested the same way?
Yes. The agent built the site and served the output locally; statuspage and fettle are examples. A static page cannot monitor anything on its own, so it answers the status-page half of the question only.
How current is this list?
Each row carries its own test date and the page states the window. A project can change after its test; a new attempt replaces the verdict only when it finishes with complete evidence.
How is this list ranked?
By measurement, not opinion: projects Argusic installed and launched on a fresh machine come first, then those that ran with mocks in place of external services, then those it could not verify. Ties go to the Argusic Score, then how popular it is on its own source.
Why are some projects unranked?
1 project is still waiting for a test or for a finished attempt. They are listed without a rank until Argusic has measured them.
More lists in this category
- observability tools (shares hertzbeat, kener with this list)
- Open source databases, installed and queried (shares hertzbeat with this list)
- self-hosted analytics (shares tianji with this list)
- self-hosted dashboards (shares gatus with this list)
- AI agent frameworks
- self-hosted AI apps
- API clients
- API gateways
- CI/CD tools
- CMS platforms
- LLM gateways
- MCP servers
- VPN tools
- backup tools
- browser automation tools
- code editors
- open source coding agents
- developer CLI tools
- e-commerce platforms
- ebook readers
- game engines
- open source games
- home automation tools
- low-code platforms
- map tools
- message queues
- Open source music servers, installed and played
- Open source office suites, installed and launched
- self-hosted password managers
- project management tools
- screen recorders
- search engines
- speech tools
- static site generators
- vector databases
- open source video editors
- video players
- web scraping tools
- whiteboard tools
- wikis
- workflow automation tools
- self-hosted Notion alternatives
- self-hosted git servers