Uptime Kuma 2.5.0 review: self-hosted monitoring verdict

Short answer: Uptime Kuma is a strong, MIT-licensed, self-hosted uptime monitoring tool for operators who want HTTP, TCP, DNS, and other reachability checks, status pages, and 90+ notification integrations (per the README) without paying per-host SaaS fees. The 2.5.0 release published August 1, 2026 is incremental, with a rootless Docker tag, an NTP monitor type, more notification providers, and dependency updates, rather than a breaking rewrite. It fits a single operator or small team best if you accept the self-hosting duties: local storage (NFS is explicitly unsupported per the README), careful network exposure, regular updates, and no public automation API, granular multi-user roles, or built-in server resource monitoring. This article is a source and documentation review of the repository, releases, and open issues as of August 4, 2026; no runtime test was performed.

Fact	Detail
Review date	August 4, 2026 (evidence snapshot)
License	MIT
Stars	89,812 at the August 4, 2026 snapshot
Language	JavaScript (Node.js)
Latest release	2.5.0, published August 1, 2026
Verification level	Observed: source and documentation review, not a runtime test

what uptime kuma is and what it monitors

Uptime Kuma is a self-hosted monitoring tool that the repository describes as “a fancy self-hosted monitoring tool.” The README lists monitoring for HTTP(s), TCP, HTTP(s) keyword, HTTP(s) JSON query, WebSocket, ping, DNS records, push, Steam game servers, and Docker containers. Notifications cover Telegram, Discord, Gotify, Slack, Pushover, email via SMTP, and more than 90 notification services. The README also claims 20-second intervals, multiple status pages that can be mapped to specific domains, ping charts, certificate info, proxy support, 2FA, and multi-language support. Those are maintainer claims from the README, not results of an independent test.

what changed in 2.5.0

According to the maintainers’ 2.5.0 release notes (published August 1, 2026), the notable additions are a new next-rootless Docker tag (#7645), unlimited monitor intervals instead of the previous 24-day cap (#7607), a new NTP monitor type (#7214), an SMTP additional-headers option (#7506), and notification providers for Plivo voice call and SMS, Ooredoo (Maldives) SMS, WxPusher, and Flowtriq DDoS detection. The release also adds a PM2 picker and platform selection for the system-service monitor and rybbit analytics tracking on status pages.

The bug-fix list includes items operators will feel: the stat_daily up/down columns were widened from SMALLINT to unsigned INTEGER (#7618), rate-limit log spam was reduced (#7599), Steam monitor hostnames are now resolved (#7542), Discord timezone handling was corrected (#7520), DNS monitor service URLs no longer include the resolver port (#7516), MQTT now accepts mqtts:// (#7290), and Kafka gained a timeout option (#7472).

On the security side, dependencies were updated (#7538, #7349) and the maintainers added a 14-day cooldown for npm updates “to minimize the supply-chain-attack” risk (#7508). Nothing in the 2.5.0 notes announces breaking changes or a data migration; it reads as a routine feature-and-fix release.

maintenance signals

The project looks actively maintained at the time of review: releases 2.3.0 (May 1), 2.3.1 (May 3), 2.3.2 (May 3), 2.4.0 (May 31), and 2.5.0 (August 1) all landed in 2026, and the repository was pushed on August 4, 2026. The snapshot shows 89,812 stars, 8,204 forks, and 776 open issues.

The 2.4.0 notes include a fix for a LiquidJS remote code execution vulnerability from an upstream dependency, described as admin-only and authenticated-only. The 2.3.x line fixed SQLite lock errors and added a UPTIME_KUMA_SQLITE_SINGLE_CONNECTION option for constrained devices, then reverted to a single SQLite connection by default in 2.3.2. That is the maintenance pattern to expect: regular releases, occasional behavior changes such as the 2.3.0 removal of status-page sorting due to poor performance, and dependency-driven security fixes.

The slower side of maintenance is features. Several high-reaction feature requests have stayed open for years: a documented API (#118, opened July 2021), multi-user role management (#128, opened July 2021), configurable heartbeat bar ranges (#1888), an exec or program monitor (#1117), and server resource monitoring (#819). If you need any of these, plan for community contributions or custom development rather than a near-term official release.

who should use uptime kuma, and under what conditions

Single operators and small teams running a Linux server or Docker host who want uptime checks, status pages, and alerts without SaaS pricing: a good fit, if you accept the self-hosting duties.
Teams that need customer-facing status pages with domain mapping and certificate info: supported per the README, but validate the behavior in a pilot before relying on it.
Anyone who needs checks from outside their own network: Uptime Kuma runs on your own host, so you must place an instance or proxy somewhere independent of the services you monitor. A self-hosted monitor cannot verify the availability of the machine it runs on.
Organizations that need API-driven provisioning, role-based user management, or server resource alerts: not currently a fit; plan workarounds or a different tool.

what to check before production

File systems like NFS are not supported; map the data directory to a local directory or Docker volume, per the README’s warning.

Storage: keep the data volume on local storage and back up /app/data before upgrades.
Network exposure: the default Docker examples listen on all interfaces at port 3001, with a 127.0.0.1:3001:3001 variant for localhost-only. Use a reverse proxy (the project documents this in its wiki) and confirm WebSocket support, since the project is built around Socket.IO and a single-page app.
Runtime if you skip Docker: the README requires Node.js >= 20.4, Git, and pm2, and lists major Linux distros plus Windows 10 and Windows Server 2012 R2 or higher; it explicitly excludes FreeBSD, OpenBSD, NetBSD, Replit, and Heroku.
SQLite behavior on constrained hosts: the 2.3.x notes describe SQLite locking issues, mainly on Raspberry Pi-style devices, with UPTIME_KUMA_SQLITE_SINGLE_CONNECTION=true as the documented escape hatch. Test at your planned monitor count and interval load.
Update plan: releases arrive regularly, so decide who applies them and when, and read release notes before upgrading because not every release is purely additive.
Alert path testing: verify every notification channel you rely on and confirm status pages show the correct public URLs.

limitations to weigh

There is no supported REST API for adding or removing monitors; the API request has been open since July 2021 and is one of the most-reacted feature requests in the repository, with a contributor note suggesting a properly documented API still needs engineering work. There is also no multi-user role model, so access control is effectively single-admin. Monitoring server health such as CPU, RAM, disk, and network is not built in; a pinned maintainer comment on issue #819 suggests implementing it through the existing post monitor rather than waiting for a native monitor type.

A long-standing issue (#275, opened August 2021) reports intermittent “timeout of 48000ms exceeded” alerts while the target site is up. The pinned comment in that thread attributes the pattern to SNAT exhaustion in constrained cloud environments rather than to Uptime Kuma. The practical lesson: when a monitor reports timeouts you cannot reproduce from the same network, check NAT, proxy, and outbound capacity before blaming the site or the tool.

alternatives and evaluation questions

For externally hosted checks, the project’s own motivation section names Uptime Robot as the inspiration; Gatus is mentioned in the #275 discussion, and HetrixTools appears in the resource-monitoring request. For CPU, RAM, disk, and network metrics, pair Uptime Kuma with a metrics stack rather than expecting it to be one.

Do checks need to originate outside your network, and can you host the monitor independently of what it monitors?
Do you need automation to create, update, or remove monitors, or is the web UI enough?
How many people need access, and do they need separate roles and permissions?
Do you need resource metrics and log correlation, or only reachability, latency, and status pages?
Is your storage local and backed up, and is your reverse proxy WebSocket-ready?
Who owns updates, backups, and the database and dependency maintenance?

verdict

Uptime Kuma is a reasonable default for self-hosted uptime monitoring when the workload is reachability checks, status pages, and notifications, and when you are comfortable running and updating your own instance. The MIT license, active release cadence, and large adoption reduce project risk. If your requirements include a documented API, role-based access, or built-in server resource monitoring, or if your data must live on shared network filesystems, evaluate other tools first or budget custom development around the gaps. This assessment is based on repository, release, README, and issue evidence collected August 4, 2026; it is not a benchmark or a production test.

sources

how I can help

I work with teams on Linux server deployment, upgrades, and troubleshooting. If Uptime Kuma fits, I can help with Docker or bare-metal setup, reverse proxy and WebSocket configuration, backup strategy, and a repeatable upgrade process. If it does not, I can help evaluate alternatives against your actual monitoring requirements. Xiang Peng, XP812.