comparing self-hosted
Uptime Kuma vs Cachet: monitor or status page?
This is not really a head-to-head. Uptime Kuma watches your services and tells you. Cachet tells your customers. Teams end up comparing them because they want both jobs done and have not yet noticed that each tool does only one of them.
the facts, side by side
| Uptime Kuma | Cachet | Uptimepage | |
|---|---|---|---|
| license | MIT | v2 BSD-3 · v3 source-available | AGPL-3.0 |
| newest tagged release | 2.4.0, May 2026 | v2.4.1, Nov 2023 · v3 untagged | 1.0.0 |
| runs its own checks | yes, 31 types | basic HTTP GET | yes, 6 types |
| who schedules the check | built in, down to 1s | a cron entry you add | built in, from 60s |
| failed check opens an incident | no, posted by hand | no, colours a component | yes, automatic |
| status page depth | basic | components · incidents · maintenance · metrics | branded, own subdomain |
| page subscribers | RSS only | email + webhook, global scope | email + webhook |
| teams & roles | single login | admin + user, no granularity | orgs + roles |
| config as code | socket API, no REST | REST, scoped tokens, OpenAPI | Terraform · REST · MCP |
| run it yourself | one container (Node) | PHP + DB + queue + cron, no v3 image | one binary + compose |
| hosted option | no | no | yes, free tier |
| community (GitHub stars) | ~89k | ~15k | young |
Cachet's newest tagged release is v2.4.1 from November 2023. The v3 rewrite ships from the dev branch, has never been tagged, and its own README says it is not yet completely ready for production use.
Cachet v3 added an HTTP GET component check in mid-2026, but nothing schedules it out of the box, it is absent from the components guide, it runs from one location, and a failure colours a component rather than opening an incident or notifying a subscriber.
Cachet's official Docker image repository covers v2 only and last saw a commit in 2021, so self-hosting v3 means a hand-rolled PHP and Laravel deployment with a database, a queue worker and cron.
Cachet 2.x was BSD-3-Clause; the v3 branch carries a custom source-available license and declares itself proprietary in composer.json, while its README still says MIT. Read the license before you build on it.
Verified July 2026 against Uptime Kuma 2.4.0 and the cachethq/core source. Both projects move quickly, so check their current source before you decide.
One watches, the other announces
Uptime Kuma is a monitor with a status page bolted on: real checks, 31 monitor types, 94 notification integrations, and a status page that is fine for a homelab but takes an RSS feed rather than subscribers, with incidents you post by hand. Cachet is the opposite: a purpose-built communication tool with components, component groups, incidents, incident updates and templates, scheduled maintenance and metrics. Its status-page domain model is the most complete of any open project in this list. It simply does not know whether anything is up.
Where Cachet stops: monitoring
Cachet v3 did add a component check in mid-2026, and it is easy to overrate. It is an HTTP GET with a three-second timeout, nothing schedules it out of the box (you add your own cron entry for the check command), it is absent from the components guide in their docs, it runs from one location, and a failure colours a component rather than opening an incident, emailing a subscriber or paging anyone. There is no on-call and no escalation anywhere in the codebase. The intended model is still bring your own monitoring, which is why Cachet ships a first-class integration for importing components and incidents from an external monitoring service.
The release state, before you commit
Read this part carefully, because the project's own sources disagree with each other. Cachet's newest tagged release is v2.4.1 from November 2023. The v3 rewrite has never been tagged: it ships from the dev branch, and its own README says it is not yet completely ready for production use. The official Docker image repository is v2-only and last saw a commit in 2021, so self-hosting v3 means a hand-rolled PHP and Laravel deployment with a database, a queue worker and cron. Development is genuinely busy, effectively by one maintainer. And where 2.x was BSD-3-Clause, the v3 branch carries a custom source-available license and declares itself proprietary in composer.json, while its README still says MIT. Check the license yourself before you build on it.
The two-system setup people actually build
The classic pairing is Kuma (or anything else) doing the checking, pushing component states and incidents into Cachet over its API, which is genuinely good: scoped bearer tokens, an OpenAPI spec, sensible resources. It works. It is also two deployments, two upgrade paths, two sets of credentials, and a piece of glue code you now own, so that a failing check in one system becomes an incident in the other.
Where Uptimepage fits
Uptimepage is that pairing collapsed into one binary. Checks over HTTP, TCP, DNS, TLS, ping and domain expiry run every 60 seconds from multiple regions, a failing check opens an incident by itself, and the incident lands on a branded status page where visitors have subscribed with confirmed email or a signed webhook. No glue code, one deployment, one set of roles. Hosted free with no card, or self-host under AGPL with docker compose.