--- title: "Healthchecks.io alternative | Logdash" description: "Cron heartbeats and HTTP uptime checks in one hosted dashboard, with Telegram and webhook alerts. Includes where Healthchecks.io is still the better tool." url: https://logdash.io/alternatives/healthchecks-io --- # 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 crontab ```bash # 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 ``` 1. **Create a push monitor** On Pro, add a monitor, choose "You send heartbeats" and copy the monitor id out of the ping URL. 2. **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. 3. **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. ### 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 AGPL-3.0 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 on Pro, with one difference that matters. A monitor goes down on the first 15-second window without a POST to https://api.logdash.io/ping/, and there is no cron expression or grace period. So a job touches a stamp file when it succeeds, and a heartbeat line pings while the stamp is fresh. ### 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. ## Keep reading [All alternatives](https://logdash.io/alternatives): One page per tool, each with the setup, the comparison and the case for staying where you are. [Checkly alternative for teams that do not need browser synthetics](https://logdash.io/alternatives/checkly): Logdash checks whether your API answers and how fast, with no browser and no test code to maintain, which is all that most Checkly accounts were actually doing. [StatusCake alternative for free uptime monitoring](https://logdash.io/alternatives/statuscake): The Logdash free plan gives you five HTTP monitors checked every five minutes, Telegram and webhook alerts and a public status page, and it says plainly which parts are paid. [Site24x7 alternative for when you only wanted a few HTTP checks](https://logdash.io/alternatives/site24x7): Site24x7 is a full IT operations suite with dozens of monitor types and a licence to match, while Logdash does HTTP checks, cron heartbeats, logs and metrics, and takes about five minutes to stand up. [Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.