Healthchecks.io alternative for heartbeats and uptime checks in one place
Logdash puts cron heartbeats and HTTP uptime checks in the same hosted dashboard, which is the better trade unless you want to self-host, because Healthchecks.io self-hosts properly today and Logdash does not.
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 project. 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 MIT 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.
Ping Logdash from the job you already run
# A push monitor takes a plain POST. No auth header, no body.
curl -fsS -m 10 -X POST https://api.logdash.io/ping/68b4c1f0e3a2d5c7b9f01234
# Chained behind && so a failed run stays silent and the monitor goes red.
* * * * * /srv/app/bin/drain-queue && curl -fsS -m 10 -X POST https://api.logdash.io/ping/68b4c1f0e3a2d5c7b9f01234- 1 Create a push monitor Add a service, set the monitor to push mode and copy the monitor id out of the ping URL.
- 2 Ping at the end of the job Append the curl to the command in your crontab. Put it behind && so a non-zero exit never reports success.
- 3 Attach Telegram Connect a Telegram channel to the monitor. The first check window that passes without a ping 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 | One POST when the job finishes | Ping, plus start, fail and exit code signals |
| Expected schedule per job | The monitor expects a ping inside every check window on your plan | 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 project, same timeline | Not part of the product |
| Public status page | Public dashboard, custom domain on Pro | Status badges you can embed |
| Open source | MIT, 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 their own odd schedules. A cron expression and a grace period per check is the right model for a backup that runs at 03:00 on Sundays, and Logdash does not have that.
- 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 one line: swap the ping URL and keep the same shell. The schedule model is the part that takes thought. A Logdash push monitor wants to hear from you inside every check window rather than by a deadline you set, so anything that runs less often than the window needs rethinking. Most people move the frequent jobs first, leave the nightly ones on Healthchecks.io, and decide later. Keep both pinging 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.
Is there an open source Healthchecks.io alternative?
Healthchecks.io is itself open source, so you may already have what you are looking for. Logdash is MIT licensed with the full source on GitHub, and adds HTTP uptime checks, logs and metrics next to the heartbeats.
Can I self-host Logdash instead?
Not in production yet. The repo runs locally for development, and a supported production install is open work tracked on GitHub. If self-hosting is a hard requirement today, self-hosted Healthchecks.io is the better call.
Does Logdash do cron job monitoring?
Yes, through push monitors. Your job sends a POST to https://api.logdash.io/ping/<monitorId> when it finishes, and the monitor goes down if a check window passes without one. There is no per-job cron expression or grace period, which is the main difference.
Which alert channels does Logdash support?
Telegram and webhooks. That is the complete list. Everything else has to go through the webhook, which means you build and keep the bridge.