Availability checks with public status pages
Uptime Kuma brings availability checks and public status pages into one self-hosted application. For a small team, the decision is whether its documented checks fit the services you operate and whether you can maintain the monitor itself. Our source-build results help assess the checkout, but do not establish how reliably it detects or reports outages.
The README lists HTTP(s), TCP, keyword and JSON-query checks, WebSockets, ping, DNS records, push signals, Steam game servers, and Docker containers. It also lists 20-second intervals, multiple status pages, domain mapping, certificate information, proxy support, and two-factor authentication. Notifications include Telegram, Discord, Gotify, Slack, Pushover, email, and a stated 90+ notification services. These are documented capabilities, not integrations we exercised.
The documented deployment path
The README provides a Compose setup ending in docker compose up -d, plus a single-container example using persistent /app/data storage. We did not execute either Docker setup, so their presence does not establish installation time, resource use, or image security.
The examples publish port 3001 on all network interfaces. The README also shows binding to 127.0.0.1 to limit exposure to localhost. Choose the binding for your intended access path, and include the persistent data in your backup plan. NFS and similar filesystems are explicitly unsupported; use a local directory or volume.
For a non-Docker installation, the README lists major Linux distributions and Windows 10 x64 or Windows Server 2012 R2 x64 or higher. It marks FreeBSD, OpenBSD, NetBSD, Replit, and Heroku unsupported. Requirements include Node.js 20.4 or newer and Git. PM2 is the documented background-process option, with separate log-rotation and startup commands.
What our recorded run establishes
Our stored run is dated August 24, 2026, at commit 34f2b6c (full SHA 34f2b6c6dd0a1039799fdb37a9735feb3a517d71). The recorded sandbox had 3 CPUs, 8 GB memory, and image label lab-node:22. The test tail identifies Node.js v20.20.2; the image label alone does not identify the runtime of every step.
Dependency installation exited 0 in 127 seconds (127,466 ms). The raw npm output says it added 1,258 packages. The separately stored dependency metric is 2,356, with 622 MB of installation storage. Those values describe different recorded quantities and should not be presented as interchangeable package counts. Repository metrics were 785 files, approximately 77,075 lines of source, and 8.3 MB.
The build exited 0 in 27 seconds (26,509 ms). This establishes that the recorded build command completed. It does not establish that the application started, that a CLI was installed, or that any monitoring workload succeeded.
The test command exited 1 in 71 seconds (71,408 ms), without timing out. The raw tail identifies assertions in test/backend-test/test-util-server.js for stripping brackets from IPv6 addresses and handling standard ASCII domains. Both received an error about executing the ping program instead of the expected error content. The tail then reports failure of npm run test-backend-20. It also includes a passing ConditionExpressionGroup.fromMonitor check; that passing check does not explain away the named failures.
The log does not establish whether the ping-program execution error came from a missing executable, permissions, or another cause. It therefore supports a failed sandbox test command, not a conclusion that deployed Uptime Kuma monitoring is broken. We have no reconciled exhaustive test count and performed no new execution for this correction.
npm audit reported 44 findings: 3 critical, 23 high, 16 moderate, and 2 low. Coverage is unknown; neither the dependency metric nor a package count in the log establishes audit coverage. The supplied record does not show advisory reachability, production-only exposure, or the contents of a published Docker image. Review current advisories against the deployment you intend to run.
Read upgrade reports at their actual scope
The supplied 2.5.3 release page lists a fix for a wrong version number and directs readers to the 2.5.1 changelog. That extract does not support a broader list of maintenance fixes.
Issue #7547 describes group monitors remaining pending after migration from 1.x to 2.4.0. The reporter later said the heartbeat table had lost its primary-key autoincrement, posted their repair, and closed the issue as completed on August 31, 2026. This is a resolved individual report in the supplied extract, not an outstanding confirmed defect across current deployments or proof of a general upstream fix.
Issue #7493 concerns Teams notification previews displaying a generic card message instead of useful service details. Commenters described workarounds, and the reporter said one restored the preview. The supplied extract shows an open feature request about notification presentation; it does not establish that all Teams alerts fail to arrive.
Before upgrading, back up persistent data and check the release notes for your versions. Afterward, verify your important monitor states and notification previews as well as delivery. These are recommended checks, not results from our run.
Which option to evaluate
Uptime Kuma fits an evaluation centered on its documented availability checks and multiple public status pages. Healthchecks addresses a more specific need: scheduled jobs send HTTP or email pings, and missing pings trigger alerts. Gatus describes itself as an automated developer-oriented status page with alerting and incident support. The supplied Gatus extract does not verify the earlier claim that its monitors should be managed in version-controlled YAML.
There is no comparative workload or installation measurement here, so these roles do not establish a winner. Start with the tool whose documented role matches your checks, then test it against your own failure and recovery cases.
How to read the ratings
These are editorial evidence ratings, not benchmark results. Across each category, 1 means substantial documented obstacles, 2 means material gaps, 3 means a usable basis for evaluation with important unknowns, 4 means strong support with limited gaps, and 5 requires broad corroborated evidence. Setup considers installation guidance and observed command completion; docs considers the supplied guidance's clarity and limits; community considers visible support and contribution routes; maturity considers documented capability and operational evidence. Unknown adoption, response times, and compatibility do not earn a high score.
The practical next step is a limited deployment with local persistent storage and deliberate network exposure. Configure representative checks, trigger a controlled failure and recovery, verify notifications, and test restoring your backup. Our recorded source run does not replace those deployment checks.