Self-hosted Cronitor alternative: know when a cron job dies with Healthchecks

A backup job that stops running doesn't announce itself. It just stops. The line is still in your crontab, the server is still up, and for weeks nobody notices — until the day you actually need that backup and there's nothing there. This is the failure mode monitoring is supposed to catch, and it's the exact one that slips through, because a job that never runs also never throws an error to alert on. Cronitor and Dead Man's Snitch built businesses on this blind spot. Healthchecks closes it, and you own the whole thing.

What Healthchecks is

Healthchecks is an open-source monitoring service for cron jobs, background workers, and any scheduled task that's supposed to run on a rhythm. It works as a dead man's switch: instead of watching your job from the outside, it waits for your job to check in. Every task gets a unique URL and pings it after a successful run. If a ping doesn't arrive on schedule, Healthchecks alerts you. That inversion is the whole point: a monitor that waits to hear from a job is the only kind that notices when the job quietly stops running at all.

It's the same codebase that powers the hosted healthchecks.io — the real tool, not a stripped-down demo. You get cron-expression schedules, grace periods, run durations, log capture, teams, and a couple dozen notification channels. The hosted alternatives meter this: Dead Man's Snitch limits how many "snitches" a tier can have, and Cronitor prices by the number of monitors. Self-hosted, the number of checks is a decision about your database, not your invoice.

The features that actually matter

None of this is a teaser tier. Everything the hosted service does, the self-hosted build does too, because they're the same software.

• Ping URLs for anything — each check gets its own URL. Append a `curl` to the end of a cron line, a systemd timer, or a CI step. Anything that can make an HTTP request can report in, and a job can even check in by sending an email instead.
• Start and success signals — hit the `/start` endpoint when a job begins and the plain URL when it finishes. Healthchecks records the run duration and can flag a job that started but never completed.
• Failure and exit-code reporting — a job can ping `/fail` or append its exit status to the URL. A nonzero exit fires an alert immediately instead of waiting out the schedule.
• Real cron schedules with grace and timezones — describe exactly when a job should run with a cron expression, set a grace window for normal jitter, and pin it to a timezone. No more approximating "every night" as a crude interval.
• A couple dozen notification integrations — email, SMS, Slack, Discord, Telegram, Matrix, PagerDuty, Opsgenie, Pushover, and generic webhooks, among others. These are the paid add-ons on the hosted services; here they're just configuration.
• Projects, teams, and read-only access — group related checks into projects, invite teammates, and hand out read-only dashboards to people who need visibility but not control.
• Status badges, an API, and log capture — public or private SVG badges for a status page, a REST API to create and manage checks from code, and the ability to attach stdout or diagnostic text to a ping so the context lives with the check's history.

Why self-host it instead of the hosted version

Your check-in data is a live map of your infrastructure — what jobs you run, how often, and when they break. On a hosted plan that map lives on someone else's servers. Self-hosted, the pings hit your box and stay there. Nobody else gets to throttle your account, retire a plan, or read the shape of your operation off a dashboard you don't control.

Then there's the pricing shape. Cronitor and Dead Man's Snitch charge by the monitor, so the more thorough you get — a check per backup, per report, per sync, per worker — the more you pay for being careful. Self-hosting inverts that: adding your two-hundredth check costs the same as adding your second. Monitoring everything becomes free instead of a budget line.

And it's yours to shape: your own domain, your own auth, a branded dashboard, internal-only notification channels, and no vendor sunsetting a tier out from under you at the moment you're relying on it.

Who it's for

• Solo operators and small teams running backups, database dumps, certificate renewals, and nightly reports who need to know the moment one goes quiet — without paying per job to find out.
• Agencies and MSPs managing scheduled work across many client servers, who want every task tracked in one place and read-only status shared with clients.
• Homelab and self-hosting enthusiasts who already run their own stack and would rather point a curl at their own monitor than sign up for yet another SaaS to watch it.
• Developers with pipelines and workers who want one dashboard for the scheduled jobs a CI system won't watch for them — nightly ETL, queue consumers, cache warmers — each reporting in with a single line of curl.

The honest setup notes

We'll be straight with you: Healthchecks is a Django application, and running it yourself means running Django yourself. It wants a real database — PostgreSQL for any serious deployment — and that database needs backups, because it holds every check and its history.

The dead man's switch is not the web app. The alerting is driven by a separate, long-running `sendalerts` process, and if that process isn't running, overdue checks never notify anyone. That's a genuinely easy thing to get wrong, and a silent monitoring system is worse than none. You'll also want SMTP configured, since email is how alerts and login links get out. The app itself is light on resources; the operational weight is in keeping those pieces alive and patched.

Or let us run it. We keep the database backed up, the alert loop running, and SMTP wired up, so the tool that's supposed to catch your failures isn't quietly failing itself.

Deploy it in one click

Rolling your own means provisioning a host, standing up Postgres, configuring the WSGI server, keeping the `sendalerts` worker supervised, wiring SMTP, and terminating TLS — then owning every one of those pieces at 4 a.m. when something drifts.

On Caliber Node you deploy Healthchecks in one click. We provision the container, attach the database, keep the alert process supervised, and hand you a working instance on your own subdomain with TLS already in place. You get real logs and SFTP access, so it's your deployment to inspect and export — just without the assembly. The difference is starting from a running monitor instead of a to-do list.

First run

1. Log in and create your first project to group related checks.
2. Add a check — give it a name and a schedule, either a cron expression or a simple period plus grace window.
3. Copy the check's unique ping URL.
4. Append it to the job you want to watch, for example: `0 4 * * * /usr/local/bin/backup.sh && curl -fsS https://your-domain/ping/<uuid>`
5. Add a notification integration — email, Slack, whatever reaches you — then run the job once and watch the check flip to green on its first ping.

From there, every job you add is another curl and another line. The monitor is doing its work the moment the first ping lands.

The bigger picture

Knowing that your automated work is still running shouldn't be a subscription you rent by the monitor. It's a basic property of a system you operate — the difference between "the backups run" and "the backups ran until March and I found out in July." Owning your monitoring means the tool watching your infrastructure answers to you, scales with your paranoia instead of your budget, and can't be paywalled at the moment you need one more check.

Deploy Healthchecks in a few minutes → https://calibernode.com/cloud-apps

Or browse the full app catalog to see what else you can own.

One-click self-hosted apps, managed for you — real logs, SFTP, and your data always exportable. Never a black box.