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 table below is the whole comparison, unedited. Read it first if you like, it is the same one we would send you.
AGPL-3.0 · one binary · free tier · no card required
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 | either direction |
| watches a URL | yes | never | yes |
| check types | 31 incl. DBs · MQTT · browser | inbound pings only | HTTP · TCP · DNS · TLS · domain · ping · heartbeat · flow |
| cron & scheduled jobs | push monitor, interval only | cron + systemd OnCalendar, timezones | heartbeat with period + grace, no cron schedules |
| job duration, exit code, output | no | yes | yes |
| 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 is alone here on cron and systemd OnCalendar schedules with timezones; a heartbeat that only knows a period cannot tell that a nightly job ran at the wrong hour.
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 does both directions. It probes over HTTP, TCP, DNS, TLS, domain expiry, ping and browser flows, and it takes heartbeats from jobs that have nothing to probe, with a period, a grace, a max run time, and the exit code and output of the run that failed. What it does not read is a cron expression, so if the question is whether last night's job ran at the right hour in the right timezone, Healthchecks 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.
- 01Sign in with GitHub or Google. No card, no sales call.
- 02Paste a URL. The first check runs before you have finished reading this.
- 03Publish the status page, or export it to Terraform and keep it in Git.
api99.98%
p95 142ms · one incident in 45 days
dashboard99.91%
p95 318ms · two degraded days
webhooks99.99%
p95 88ms · no incidents
RESOLVED14 min
Elevated latency on the dashboard API
14:22 resolved, latency back under 300ms
14:08 opened automatically by the dashboard check
up degraded down 45 days · email & webhook subscribers