Healthchecks.io Alternatives When You Already Run Kuma: Cron Pings That Still Lie

You already run Uptime Kuma. The status page is public or it is not. HTTP checks are green. Someone on a forum says you still need Healthchecks.io for cron, because Kuma is for “is the site up” and Healthchecks is for “did the job run.” You add a Kuma push monitor instead, to keep one dashboard. A month later the backup cron died after it printed “starting” and Kuma stayed green because the ping happened at the top of the script. The ping did not lie. The script did. The dashboard agreed with the ping.

I treat cron heartbeats as a claim to verify, not as a backup. I have watched Healthchecks stay green while a destination folder aged two months. I have watched Kuma push do the same with a shorter grace and a prettier chart. If you already run Kuma, the question is not “which logo.” It is where the ping sits in the script, and whether a second, dumber checker would have caught the lie.

What Kuma already gives you

Kuma push monitors are Healthchecks-shaped: a URL the job must hit, a period, a grace, a red tile if the hit is late. You can notify through the same ntfy or Pushover path you already fought with. You do not need a second account for the simple case: one box, a handful of timers, you will look at Kuma anyway.

Kuma is weaker as a cron product than as an HTTP product. The push monitor is a late addition in spirit even if it has been there a while. You do not get Healthchecks’ nice slug management, the badge culture, the “this job is expected 3 times a day on weekdays” calendar, or the simple status page that is only heartbeats. You get a row next to “is the blog returning 200.” That mixing is why people miss a dead cron. The page is mostly green. The one push row is a small red you trained yourself to ignore because the HTTP rows flap when the cable modem burps.

If your Kuma is already noisy, adding push monitors to it is how cron death becomes more noise. That is a reason to look at alternatives even though you “already run Kuma.”

Healthchecks.io — still the default other brain

Healthchecks.io, hosted or self-hosted, is still the thing I add when Kuma is busy being a website watcher. The UI is for cron. The cron integration docs are for cron. The ping happens, you can ping start and success, you can attach a log snippet. The start/success pair is the feature Kuma users skip. If you only ping at the top, every tool will lie. If you ping start and then success, a hang looks different from a skip.

Hosted Healthchecks is cheap and is another vendor. Self-hosted Healthchecks is another compose file. I will add the compose file when I do not want cron health on the same host as the jobs. Same-host Healthchecks dies with the NAS that missed the backup. That is the ntfy-on-the-NUC problem in a different hat.

If you already have Kuma on the NAS and you add Healthchecks on the NAS, you bought two UIs and one fate. Put Healthchecks on the VPS, or use the hosted product, or do not bother.

Cronitor, Dead Man’s Snitch, Better Stack

Cronitor is the paid, polite version: good at schedules, good at “this should not run on Sunday,” good at telling a client their job failed without sending them your Kuma. I use it when the cron is for someone else. I do not use it for a homelab that already has three alerting paths.

Dead Man’s Snitch is older and still excellent at the one job: if this does not check in, mail me. Fewer features. Harder to turn into a second career. For a one-person lab it can be enough, and it is not Kuma, which is the point if Kuma is already a junk drawer.

Better Stack (once Better Uptime) will eat heartbeats and HTTP and logs if you want to pay to consolidate away from Kuma. That is the opposite of this article’s premise. If you already run Kuma and like it, do not migrate for a heartbeat. Add a heartbeat tool. Do not throw away the HTTP checks that work.

Healthchecks-compatible clones and “just a webhook to ntfy on a timer” scripts exist. A raw ntfy canary is not a cron monitor. It does not know the job’s period. It knows you have not spoken. I use a canary for “is the messenger alive.” I use a real heartbeat for “did restic finish.”

Why the ping still lies in every product

The lie is almost never the SaaS. The lie is the line you put in crontab:

• restic backup && curl ping — if restic is killed, you might still have pinged from a wrapper that used ; instead of &&.
• Ping at the start, never at the end. The job can run for 40 minutes and die. The monitor is on a 25-hour grace. Green.
• The job runs on a machine whose clock jumped. Period math gets weird. Rare. Hilarious.
• The job runs, succeeds, and writes to a disk you unmounted. The ping cannot see the folder. I have lived this. The monitor will not save you. A check of the destination size will. That is a different monitor, or a script that pings only after du matches a floor.
• Kuma or Healthchecks is down, the job is fine, you get a panic. Or the reverse: both on one UPS.

Diana-mode rule: the heartbeat is a claim. Verify the artifact. A second tool does not fix a first-line ping. Moving the ping to the end, or using start/success, fixes more than switching logos.

What I run when Kuma is already there

HTTP and ICMP and keyword checks stay in Kuma, where they belong and where I already look on a Monday.

Cron that guards data gets Healthchecks hosted, or Healthchecks on a VPS, with start and success pings, and a monthly “does the restore folder have a file newer than 32 days” that is a separate Kuma HTTP check against a tiny endpoint I generate, or a manual drill. I do not put the restic heartbeat only in Kuma if Kuma is already a Christmas tree.

If I am too stubborn to add Healthchecks, I still split: a dedicated Kuma tag and a notification channel that is not the same as “blog flapped.” I still move the ping to the end. I still do not ping from the same compose stack I am backing up without a second opinion.

Cronitor gets the one job I will be embarrassed to miss in front of someone else. Dead Man’s Snitch gets nothing new from me; I am not anti, I am already paying Healthchecks. Better Stack is for people who want to leave Kuma. This article assumes you do not.

Self-hosted Healthchecks versus another Kuma

A second Kuma instance just for push monitors is a pattern I have seen and I understand it. Different noise, different notification channel, same software you already know. It works. It is also two Kumae to upgrade. Healthchecks is smaller in the head if the only job is heartbeats. I would rather learn one small app than operate two copies of a big one. If you refuse new apps on principle, the second Kuma is valid and you should still move the ping to the end of the script. Principle does not place the curl.

I do not run two Kumae. I run one, and I run Healthchecks for the jobs that would make me sick to miss. That split is enough. A third brand would be collecting.

A decision you can make tonight

Open the crons that would hurt. For each, write down where the ping is and what artifact would prove it. If the ping is at the top, move it before you create an account. If Kuma push is already correct and quiet, stop. You do not need alternatives. You needed a better line in crontab.

If Kuma push is correct and you still missed an event because the page is a junk drawer, add Healthchecks or Snitch for those few jobs only. Do not import every HTTP check into a new product. Do not run three heartbeat brands. Two brains is plenty: Kuma for “is it answering,” a cron specialist for “did it finish.”

The alternatives to Healthchecks.io when you already run Kuma are: Kuma push done honestly, Healthchecks anyway on a different host, Cronitor for client-facing jobs, Snitch for stubborn simplicity. The alternative that does not work is a new logo and the same curl on line one. Cron pings will still lie. I will still open the destination folder on disk. If that sounds like distrust of software I recommended two paragraphs ago, it is. Heartbeats are a courtesy from a script. Courtesy from a script is not a restore.