Cronitor alternative for cron jobs and uptime in one tool
Logdash watches background jobs with push heartbeats and HTTP endpoints with scheduled checks in the same dashboard, alerting to the same Telegram channel when either one goes quiet.
Cronitor is the best cron monitor there is at the cron part, and that is worth saying before anything else. It parses the schedule you give it, so it can tell you a job never started rather than only that a job failed. The CLI wraps the command, captures the exit code and the output, and a discover command reads a crontab and creates the monitors for you. Fifty jobs across ten boxes is exactly the problem it was built for.
The reason to look elsewhere is usually consolidation. Cron jobs are one of the three things you actually watch. The other two are whether the API is answering and what the logs said at the second it stopped. Running a cron monitor, an uptime monitor and a log tool means three bills, three alert configurations, and three tabs to correlate at the precise moment you have no patience for tabs.
Logdash puts them in one dashboard: a push monitor for the job, an HTTP monitor for the API, and logs and metrics from the same app through an SDK. The ping is a plain POST with no auth header and no body. Know the catch up front. Push monitors are on Pro and expect a ping in every 15-second window, with no schedule and no grace setting, so a job that pings once per run, even every minute, reads as down between runs. A scheduled job leaves a stamp when it succeeds, and a heartbeat line pings every 5 seconds while the stamp is fresh.
A stamp and a heartbeat in the crontab
# Once: mkdir -p /var/lib/heartbeat
# The job. The stamp moves only when it exits 0.
*/15 * * * * /srv/app/bin/drain-outbox && touch /var/lib/heartbeat/drain-outbox
# The heartbeat. Pings every 5 seconds while the stamp is under 20 minutes old.
* * * * * for i in $(seq 12); do find /var/lib/heartbeat/drain-outbox -mmin -20 2>/dev/null | grep -q . && curl -fsS -m 4 -o /dev/null -X POST https://api.logdash.io/ping/6710b3f2c9a14e0021d9f8ab; sleep 5; done- Create a push monitor On Pro, add a monitor, choose "You send heartbeats", and copy the ping URL. The id in that URL is the only thing the endpoint needs.
- Paste both lines Add the job and the heartbeat to the crontab, then run the job once by hand so the stamp exists. The -mmin value is the schedule plus the lateness you accept.
- Comment the job out Connect a Telegram channel and disable the job. Once the stamp passes 20 minutes the pings stop, and within 30 seconds Telegram tells you the job stopped running, the failure mode that never shows up in your error tracker.
Logdash vs Cronitor
| Feature | Logdash | Cronitor |
|---|---|---|
| Schedule awareness | None, the stamp age in your crontab stands in | Parses the schedule and knows when a run is late |
| Ping shape | One public POST, no auth, no body | Ping URLs with run, complete and fail states |
| Exit code and output capture | Not built | The CLI wraps the command and keeps both |
| HTTP uptime checks in the same tool | Yes, same dashboard | Also included |
| Application logs and custom metrics | Eight SDKs into the same dashboard | Job output, not application logging |
| Free plan | HTTP checks only, push monitors need Pro | Free tier for a small number of monitors |
| Source code | AGPL-3.0 licensed, public repository | Closed platform, open source clients |
When Cronitor is the better pick
- You want schedule-based cron monitoring, where it is the better pick today. Cronitor reads the schedule and applies a grace period. Logdash needs a stamp and a heartbeat line per job.
- You have a lot of jobs. Reading a crontab and creating the monitors automatically beats pasting curl lines by hand across ten hosts.
- You need to know a run started, ran too long, or exited non-zero, not only that it finished. Logdash sees one ping and nothing around it.
- You want the job output attached to the alert so you can read the traceback without opening an SSH session first.
Moving a crontab across
Two lines per job, not a URL swap: the && touch on the job and a heartbeat that reads the stamp. Leave the Cronitor ping in place for a week and check both agree about which runs happened. The schedule parsing does not transfer, so you set each threshold by hand, and the ping endpoint allows 300 requests a minute per IP, which caps one host at 25 heartbeat lines. If that is more plumbing than you want, keep the jobs on Cronitor and move only the uptime checks.