Uptime Kuma vs Healthchecks

Uptime Kuma and Healthchecks both live in the "monitoring" category, both are light enough to run on almost any VPS, and both will alert you the moment something in your infrastructure stops behaving. Past that, they answer different questions. Uptime Kuma watches your services from the outside — does this URL, port, or host still respond? Healthchecks watches them from the inside — did this scheduled job actually run? Framing this as a head-to-head misses the point a little, but if you can only stand up one monitor today, one of them is the better place to start, and it is worth saying plainly which.

Two different failure modes

Uptime Kuma is an active checker. It reaches out to the things you tell it to watch — an HTTP endpoint, a TCP port, a ping target, a DNS record — on a schedule, and it complains when the response is wrong or missing entirely. This is the failure mode most people think of first: the site is down, the API stopped answering, the certificate expired.

Healthchecks is a passive receiver, and its model is inverted. It never requests anything. Instead, your own job — a backup script, a cron task, a background worker — pings a unique URL when it finishes successfully. If that ping is late, or never arrives, Healthchecks raises an alert. This catches a failure mode that an endpoint checker cannot see at all: the job that silently stopped running. A cron entry that got removed in a deployment, a script that started throwing an exception before it reaches the success line, a backup that quietly hasn't run in three weeks — none of that shows up as a broken URL, because there is no URL involved. It only shows up as a ping that stopped arriving.

Neither tool can do the other's job. Uptime Kuma has no concept of "did a scheduled task run." Healthchecks never makes an outbound request, so a web server serving 500 errors to every visitor stays invisible to it forever. They overlap in the sense that both live under "monitoring" — they do not overlap in what they actually watch.

What each one checks

Uptime Kuma's coverage on the active-checking side is broad: HTTP(s), TCP port, ping, DNS, keyword and JSON-query matching inside a response body, and certificate-expiry tracking, plus push monitors for the rare case where you want something closer to Healthchecks' model without leaving the app. Its notification list is unusually long — it reaches most of the services people already use for alerts.

Healthchecks' surface is narrower by design, because it only does one thing: receive a ping and track whether it arrived on schedule. Each check gets a unique URL; your job curls it (or hits it with any HTTP client) on success, and a grace period defines how late is too late before an alert fires. It also supports a "start" ping to measure how long a job took, which Uptime Kuma has no equivalent for.

Setup

Uptime Kuma is a single Node container. Open the web UI, click Add Monitor, fill in a target and an interval, and you're watching it — no file to write, no second service to stand up. That simplicity is the whole appeal, and it means a teammate who has never touched the server can add a check on their own.

Healthchecks is a Django application backed by PostgreSQL — the reference Compose file builds the image from a checkout and brings up both the web app and the database together. Setup means cloning the repo, filling in a handful of environment variables (SECRET_KEY, database credentials, ALLOWED_HOSTS, SITE_ROOT), bringing up the stack, and creating a superuser through a management command. Once it's running, creating a check is a couple of clicks in the same web UI style as Uptime Kuma — the extra weight is entirely in getting the app itself online, not in day-to-day use.

Footprint, measured

Both were installed fresh on identical GCP e2-standard-2 instances running Ubuntu 26.04 and measured idle at first boot in August 2026. Uptime Kuma came in at ~106 MB idle and ~692 MB disk — a single Node process with its embedded database, about as light as a monitoring tool gets. Healthchecks measured ~274 MB idle, split roughly between its web process (~242 MB) and PostgreSQL (~32 MB), and ~1.9 GB disk, which includes the build cache its from-source Compose setup creates rather than pulling a prebuilt image. Neither number should drive the decision on its own — both fit comfortably on the cheapest VPS any provider sells, with plenty of headroom left for the services being watched.

Notifications and status pages

Both tools cover the essentials, and the gap here is smaller than the footprint gap suggests. Uptime Kuma supports status pages built and styled directly in its UI, and its notification integrations run unusually long, including self-hosted push options like Gotify and ntfy alongside the usual chat and paging services. Healthchecks alerts primarily over email out of the box, with webhook and integration support for routing missed pings wherever you need them — its job is narrower, so the notification story is simpler by design rather than by limitation.

Which should you self-host?

Pick Uptime Kuma if…

• You want a monitor running in the time it takes to start one container, with nothing to write first.
• Your primary worry is "is this site or service reachable right now" — the classic uptime question.
• More than one person adds checks, and a click-through web UI matters more than a database-backed deploy.

Pick Healthchecks if…

• Your primary worry is silent failure — a backup, cron job, or background worker that stops running without ever throwing an error anyone sees.
• You already have Postgres available, or don't mind standing up the small stack that comes with the reference Compose file.
• You want a "start" ping to catch jobs that are running too long, not just jobs that never ran.

Or run both

If you serve something to the public and also depend on scheduled jobs behind the scenes — and most self-hosted setups do — the honest answer is to run both. Together they still measure well under a gigabyte idle, and they cover the two failure modes that neither one can see on its own.

Running both on a VPS

Both are light enough to share a box with the services they watch, with the usual caveat: a monitor on the same host as what it's watching cannot tell you the whole host went down. If uptime numbers matter to you, put Uptime Kuma on a separate machine, ideally with a different provider, so a checker and its target don't fail together. Healthchecks doesn't have that same constraint — it receives pings rather than making them, so where it runs matters less, as long as the jobs pinging it can reach it. Terminate TLS in front of either one; Healthchecks in particular listens on plain HTTP with no TLS of its own and treats each check's ping URL as effectively a secret. The Uptime Kuma and Healthchecks deploy guides walk through both installs step by step, and our Uptime Kuma vs. Gatus and Uptime Kuma vs. Beszel comparisons cover the other adjacent tools worth knowing about in this category.