Healthchecks.io vs Cronitor for Cron Job Monitoring: Grace Periods, Free Tiers and Alert Routing

Cron jobs fail in the quietest way possible. A website that goes down gets noticed by someone. A nightly backup that stops running gets noticed by nobody, until the day you need the backup. Then you learn it last ran in March.

The fix is a dead man’s switch: each job checks in with a monitoring service when it runs, and the service alerts you when a check-in does not arrive on time. Healthchecks.io and Cronitor are the two services most people end up choosing between. Both do the basic job well. They differ in what they assume about you: Healthchecks.io assumes you will wire things up yourself and wants to stay simple and open; Cronitor assumes you want more done for you and more insight into each run.

I have used both to watch backups, database dumps, certificate renewals and report jobs, and I treat every green check as a claim to verify rather than a fact. Here is how they compare where it counts.

Simple and open, or automated and opinionated

Healthchecks.io is the better choice for most homelabs and small projects. It is simple, generous, open source, and you can self-host it if you want to. A one-line curl at the end of a job is all it takes.

Cronitor is the better choice when you want automatic setup across many servers, detailed telemetry for each run, and rules about what a successful run looks like, not just whether it happened. It costs more, and it is a hosted service only.

How the dead man’s switch works

Both services follow the same model. You create a check (Healthchecks.io) or a monitor (Cronitor) for each job and get a unique URL. Your job requests that URL when it finishes. You tell the service how often to expect a ping, either as a simple period (“every 24 hours”) or as a cron expression (“2:30 every night”). If a ping does not arrive in time, plus a grace period, you get an alert.

Both also support richer signals. A job can report when it starts, so the service can measure how long it ran and notice a job that started but never finished. It can report an explicit failure, so a job that runs but errors out alerts you immediately, instead of after the grace period. Using all three signals, start, success and failure, turns a simple “did it run?” into “did it run, how long did it take, and did it work?”.

Setup: one curl versus a CLI that finds your jobs

Healthchecks.io setup is deliberately minimal. Create a check, copy its URL, and add a request to the end of the job:

30 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 5 https://hc-ping.com/your-uuid

The && matters: the ping only happens if the backup exits successfully. To report failures and duration too, wrap the job in a small script that pings /start first and the result at the end, or use a wrapper such as runitor, which does that for you and sends the job’s output with the ping. It takes a few minutes per job, and every piece is visible and easy to change.

Cronitor’s approach is more automated. Its command-line tool can read the crontab on a server, list the jobs, and create a monitor for each one, wrapping them so every run reports its start, finish, exit status and output. On a server with twenty cron jobs, that saves a lot of copying and pasting, and it makes it much less likely you forget one. Cronitor also has SDKs for languages and job frameworks, so scheduled jobs in your application code can report in without shell scripts.

If you have one homelab box with five jobs, the Healthchecks.io approach is quick and transparent. If you look after several servers with many jobs, Cronitor’s discovery is a real time saver.

Grace periods and schedules

The grace period is the setting people get wrong most often. Set it too short and every slow run pages you. Set it too long and a dead job goes unnoticed for most of a day.

A good starting point: set the grace period a little longer than the longest normal run. If your backup usually takes 20 minutes and occasionally 45, a one-hour grace period catches a missing run within about an hour of when it should have finished, without false alarms on slow nights.

Both services accept cron expressions with a time zone, which matters more than it seems. A job scheduled in local time behaves differently on the two nights a year when the clocks change: it can run twice or not at all. If the monitor and the job disagree about the time zone, you get a false alarm or a missed one. Configure both in the same zone, or use UTC everywhere, and read up on how cron jobs behave when DST hits if your jobs run in the small hours.

The real problem: jobs that succeed at doing nothing

Here is the failure neither basic setup catches: a job that runs on time, exits with success, and does nothing useful. The backup script runs, but the source path changed and it backed up an empty folder. The export job runs, but the query returned no rows. The ping arrives, the dashboard is green, and the data is gone.

This is where the two services differ most.

Cronitor lets you define what success looks like. You can set rules on run duration: a backup that normally takes 20 minutes and finishes in 4 seconds is suspicious, and Cronitor can alert on that. Jobs can also report metrics such as a count of records or files processed, and you can set assertions on those, such as “alert if fewer than 100 files were backed up”. That moves monitoring from “did it run?” to “did it do the job?”.

Healthchecks.io leaves that judgement to your job. It records how long each run took, so you can spot a suspiciously short run in the history, and your script can send the job’s output with the ping for later inspection. But deciding that a run was bad is up to your script, which must check its own result and ping the failure URL. That is perfectly workable: a few lines comparing the backup size to yesterday’s will do it. It is just work you have to remember to do.

Neither service can tell you whether a backup actually restores. A green ping proves the job finished; it does not prove the data is usable. That is why restore drills still matter even with perfect monitoring.

Alerts and integrations

Healthchecks.io supports a long list of notification channels: email, Slack, Discord, Telegram, Signal, ntfy, Pushover, PagerDuty, webhooks and many more. For a homelab, sending alerts to ntfy or Pushover on your phone is a good setup, and it is all available on the free tier.

Cronitor covers the mainstream channels: email, Slack, SMS, PagerDuty, webhooks and others. It is aimed more at teams, with features for routing alerts to the right people and escalating them. For one person it works well, but you are paying partly for team features.

Whichever you choose, send alerts somewhere you will actually see them on a bad day. An alert that lands in a mailbox you check weekly is not an alarm.

Open source, self-hosting and price

Healthchecks.io is open source. The hosted service has a free tier suitable for a typical homelab, and the same software can be self-hosted if you want everything on your own hardware. That makes it a natural fit for people who self-host on principle. But think carefully before you self-host your dead man’s switch: if it runs on the same machine as the jobs it watches, the machine dying takes the monitor with it, and you get silence instead of an alert. The hosted version avoids that problem.

Cronitor is a commercial hosted service. Its free tier is smaller, and its paid plans cost more than Healthchecks.io’s, reflecting the extra features: uptime monitoring, status pages, team tools, telemetry and assertions. If you would otherwise pay for a separate uptime monitor, Cronitor covering both can balance out.

Free-plan limits change over time for both services, so check the current pricing pages before you plan around a specific number of checks.

Picking the watchdog for your jobs

Healthchecks.io is the better fit when:

• You run a homelab or a small project with a handful of scheduled jobs.
• You are comfortable adding a curl line or a small wrapper to each job.
• You want a generous free tier and alerts to ntfy, Pushover, Telegram or Signal.
• You value open source and the option to self-host.

Cronitor is worth paying for when:

• You look after several servers with many cron jobs, and automatic discovery saves you hours.
• You want alerts on suspicious runs, such as too fast, too slow or too few records, without writing that logic yourself.
• Your scheduled jobs live in application code, and an SDK fits better than shell scripts.
• You also want uptime checks and status pages in the same place.

The service matters less than the habit. Every job that matters should report in. Every report should mean the job worked, not just that it ended. And someone, at least once in a while, should check that the thing being backed up can actually be restored. A green dashboard is a claim, and the restore is the proof.