comparing self-hosted
Uptime Kuma vs Healthchecks: they don't do the same job
These two get compared constantly, and the comparison usually starts from a wrong assumption. Uptime Kuma calls your service to see if it answers. Healthchecks never calls anything: it sits and waits for your cron job to call it, and complains when the call does not arrive. Everything else follows from that direction.
the facts, side by side
| Uptime Kuma | Healthchecks | Uptimepage | |
|---|---|---|---|
| license | MIT | BSD-3-Clause | AGPL-3.0 |
| how a check works | it calls your service | your job calls it | it calls your service |
| watches a URL | yes | never | yes |
| check types | 31 incl. DBs · MQTT · browser | inbound pings only | HTTP · TCP · DNS · TLS · ping · domain |
| cron & scheduled jobs | push monitor, interval only | cron + systemd OnCalendar, timezones | heartbeat over the API, not in the UI |
| job duration, exit code, output | no | yes | no |
| fastest granularity | 1s | 60s ping period | 60s free · 30s Pro · 10s self-hosted |
| status page | basic | badges only | branded, own subdomain |
| page subscribers | RSS only | none | email · webhook |
| alert integrations | 94 services | ~28 incl. Signal · Apprise | 14 native |
| config as code | socket API, no REST | REST API, community Terraform | Terraform · REST · MCP |
| teams & roles | single login | projects + 4 roles | orgs + roles |
| run it yourself | one container (Node) | one container (Django, SQLite) | one binary + compose |
| hosted option | no | yes, 20 checks free | yes, free tier |
| community (GitHub stars) | ~89k | ~10k | young |
Healthchecks never makes a request to your service; your service must make a request to it. It cannot tell you a website is down, by design.
Uptime Kuma's push monitor covers the simple dead-man's-switch case. Healthchecks adds cron and systemd OnCalendar schedules with timezones, job duration, exit codes and captured job output.
Healthchecks' Terraform provider is community-maintained, not official.
Verified July 2026 against Uptime Kuma 2.4.0 and Healthchecks v4.2. Both projects move quickly, so check their current source before you decide.
One calls you, the other waits for your call
Uptime Kuma is an active prober. It sends the request, reads the answer, and decides. Healthchecks is a dead man's switch: your backup script, your cron job, your nightly report pings a URL when it finishes, and Healthchecks alerts when a ping is late or missing. That means Healthchecks cannot tell you your website is down, ever, and that is by design rather than an omission. If your cron job keeps pinging happily while your site returns 500s, Healthchecks stays green.
What Healthchecks is genuinely best at
Knowing whether a scheduled job ran, and ran correctly. It takes cron expressions and systemd OnCalendar schedules with timezones, so it alerts when a job did not run at the right time rather than merely when an interval elapsed. Signal a start and a finish and you get duration; ping the failure endpoint and you get the exit code; send a body and it keeps the job's output next to the ping. Nothing in the uptime-monitoring category does that properly. It is BSD-licensed, runs as one container on SQLite, and its free hosted tier is 20 checks forever.
What Uptime Kuma is genuinely best at
Reach and immediacy. The 2.x line covers 31 monitor types including databases, MQTT, SNMP, gRPC and a real Chromium browser check, notifies 94 different services, and drops its minimum interval to one second. It is one container and a five-minute install. It also has a push monitor, which is a simple dead man's switch, and that overlap is the reason people ask this question at all.
The overlap, and where it breaks
Kuma's push monitor handles the easy case: something should check in every N minutes, tell me when it stops. Reach for Healthchecks when the schedule itself is the thing you care about, because a push monitor understands an interval and nothing else. It does not know that your job is supposed to run at 03:00 in Europe/Helsinki, it will not tell you the run took nine minutes when it usually takes two, and it will not keep the failing job's stack trace for you. Going the other way, Healthchecks will never watch a URL. Plenty of teams run both, and that is a reasonable answer rather than a cop-out.
Where Uptimepage fits
Uptimepage is on Kuma's side of the line and does not pretend otherwise: HTTP, TCP, DNS, TLS, ping and domain checks that go out and ask. If cron correctness is your actual problem, use Healthchecks; it is better at that than we are. What Uptimepage adds over both is the part neither one covers, which is the customers. A branded status page on your own subdomain, confirmed email and webhook subscribers, incidents opened automatically from failing checks, organizations with roles instead of one shared login, and a Terraform provider, REST API and MCP server. Hosted free with no card, or self-host under AGPL.