heartbeet vs Healthchecks.io
Healthchecks.io is the veteran here: open source, generously free, run by one person for a decade. if you end up there instead, you picked well. here's where the two actually differ, so you can pick for the right reasons.
the core difference: configured periods vs learned rhythm
Healthchecks asks you to declare a period and a grace period per check ("expect a ping every 30 minutes, allow 5 late"), or a cron expression. that's explicit and predictable, and when a job's schedule changes you update the check.
heartbeet doesn't ask. the beets learn each job's rhythm and its natural variability from the heartbeats themselves, and size each job's deadline from what they've seen. a metronomic job gets a tight leash, a naturally wobbly one gets the slack it needs, and a schedule change is just… learned. the trade: heartbeet's deadline is a calibrated estimate, not a number you typed; if you want to assert "page me at exactly minute 35", Healthchecks' model is more direct (heartbeet does support per-job overrides for some settings on paid plans, but they're the escape hatch, not the workflow).
the same difference shows up every time you add a job: in Healthchecks the new check exists because someone created and configured it; in heartbeet a new job exists because it has a heartbeat: a new POST someone added in a PR. nothing to create first, nothing to keep in sync, and it shows up on the live dashboard on its own.
side by side
| — | heartbeet | Healthchecks.io |
|---|---|---|
| configuration | none; rhythm + grace period are learned per job | period + grace period, or a cron expression, per check |
| free tier | 2 projects, unlimited jobs, unlimited api keys, 48h history | 20 checks, 100 log entries per check |
| paid (individual) | backer, $5/mo: unlimited projects, per-job tuning, arrhythmia paging, 90d history | supporter, $5/mo: same limits as free, it's a thank-you tier |
| paid (work) | team, $20/mo: teammates with their own logins, tag-routed recipients, history forever | business, $20/mo: 100 checks, SMS/WhatsApp/phone credits, email support; $80/mo for 1000 checks |
| alert channels | email (Slack, SMS, webhooks on the roadmap) | email plus a very long integration list (Slack, SMS, PagerDuty, webhooks, …) |
| early warning | arrhythmia paging: two consecutive late heartbeats page before a flatline | — |
| pausing | deploy-shaped: drain + wait windows, per job or per tag, from the project page or any project api key | pause per check (UI/api); resumes on the next ping, or sticky until resumed |
| self-hosting | no | yes, open source (BSD) |
| jobs created by | the first heartbeat; no registration step | creating a check first (auto-provisioning available via api/slug modes) |
pick Healthchecks.io if
- you want to self-host; it's open source and good at it, and heartbeet simply isn't self-hostable.
- you need Slack/SMS/PagerDuty delivery today, not on a roadmap.
- you think in cron expressions and want the monitor to share your crontab's vocabulary exactly. heartbeet will never support this, and it's a deliberate non-feature: the whole point is a configuration-free lifestyle, where you can change how your jobs run without ever updating the monitoring to match.
pick heartbeet if
- you don't want to maintain period/grace config for dozens of jobs; you'd rather let the beets do the bookkeeping.
- your jobs are many and small: the free tier caps projects, not jobs.
- you want the early warning of arrhythmia paging, not just the flatline.
- you like a tool with a pulse (literally; the beets learn yours).
try it from the quickstart; the free tier needs no card and the first heartbeat is one curl.