Healthchecks.io alternative for heartbeats and uptime checks in one place
Logdash puts heartbeats and HTTP uptime checks in the same hosted dashboard, which is the better trade when you want both on one timeline, while Healthchecks.io stays the better pick for schedule-based cron jobs and for self-hosting.
Healthchecks.io watches jobs that are supposed to call it, and it does that well. Almost nobody leaves because it broke. They leave because it is one of three tabs. Heartbeats live in Healthchecks.io, uptime checks live somewhere else, logs live in a third place, and a failed nightly job plus the 500s it caused become two separate investigations at 3am.
Logdash runs both directions in one domain. Pull monitors hit a URL on a schedule and record the status code and the response time. Push monitors sit and wait for your job to call in. Same alert channels, same uptime history, and the logs your SDK sends land beside them. When the queue drains late and the API starts handing out 503s, the two sit next to each other on one timeline instead of being reconstructed from timestamps in two tabs.
The honest part first. Healthchecks.io is open source and the self-hosted build is the same code that runs the hosted service, so you can have it on your own box tonight. Logdash is AGPL-3.0 licensed with the source on GitHub, but self-hosting is not a one-command install today. It runs locally for development, and production self-hosting is open work tracked on GitHub. If self-hosting is why you are reading this, stay where you are.
Watch the job you already run
# Once: mkdir -p /var/lib/heartbeat
# The job, chained behind && so only a clean exit moves the stamp.
*/5 * * * * /srv/app/bin/drain-queue && touch /var/lib/heartbeat/drain-queue
# A push monitor wants a ping in every 15-second window, so this line pings
# every 5 seconds while the stamp is under 10 minutes old. Plain POST, no auth.
* * * * * for i in $(seq 12); do find /var/lib/heartbeat/drain-queue -mmin -10 2>/dev/null | grep -q . && curl -fsS -m 4 -o /dev/null -X POST https://api.logdash.io/ping/68b4c1f0e3a2d5c7b9f01234; sleep 5; done- Create a push monitor On Pro, add a monitor, choose "You send heartbeats" and copy the monitor id out of the ping URL.
- Stamp the job, ping from a heartbeat Append && touch to the job so a non-zero exit never moves the stamp, then add the heartbeat line. Run the job once by hand so the stamp exists.
- Attach Telegram Connect a Telegram channel to the monitor. Once the stamp goes stale the pings stop, and the next empty 15-second window sends the alert to Telegram.
Logdash vs Healthchecks.io
| Feature | Logdash | Healthchecks.io |
|---|---|---|
| HTTP uptime checks | Pull monitors record status code and response time | Heartbeats only, nothing reaches out to your URL |
| Heartbeat signals | A ping in every 15-second window, silence is the failure | Ping, plus start, fail and exit code signals |
| Expected schedule per job | None, the stamp age in your crontab stands in | A cron expression and a grace period per check |
| Alert channels | Telegram and webhook, and that is the whole list | A long list of integrations out of the box |
| Logs and metrics beside the monitor | Eight SDKs, same dashboard, same timeline | Not part of the product |
| Public status page | Hosted page, plus public JSON for your own build | None, badges instead |
| Status badges | SVG badge per monitor, in 3 styles | SVG, JSON and Shields.io badges |
| Open source | AGPL-3.0, full source on GitHub | Open source, full source on GitHub |
When Healthchecks.io is the better pick
- You want to self-host in production. Their self-hosted build is the same code as the hosted service. Ours is not there yet, and saying otherwise would waste your evening.
- Your jobs run on schedules. A cron expression and a grace period per check is the right model for a backup that runs at 03:00 on Sundays, which makes Healthchecks.io the better pick for cron monitoring today.
- You need the alert somewhere Logdash cannot send it. A webhook bridge you build and then maintain is still a thing you maintain.
- Nothing you own answers HTTP. If you only ever watch jobs, half of Logdash is dead weight.
What moving over actually takes
Per job it is two lines, not a URL swap: the && touch on the job and a heartbeat that turns the age of the stamp into pings. A Logdash push monitor wants a ping in every 15-second window rather than by a deadline you set, so no scheduled job can ping it directly, every-minute jobs included. Workers that loop all day are the easy move: a canary that pings every 5 to 10 seconds. Keep both running for a week while you do it. A duplicate heartbeat costs nothing, and running them side by side is how you find out that one of your jobs has been quietly failing since a deploy in March.