Cron job monitoring
for missed runs.

Cron job monitoring checks that scheduled tasks actually run. Each job pings a unique URL when it finishes, and the monitoring service alerts you when a ping doesn’t arrive on schedule. It catches what logs can’t: a job that never started writes no error at all. Hyperping calls these monitors healthchecks.

Create a healthcheck with the job’s schedule, as an interval or as its cron expression and timezone, and a grace period. Copy its ping URL and add a request to the end of the job, such as && curl -fsS followed by the URL in your crontab. If the ping doesn’t arrive by the expected time plus the grace period, Hyperping alerts you.

The same idea under other names. Instead of a monitor checking your service, your job sends a signal, the heartbeat, on every run, and the alert fires when the signal stops. It suits anything with no URL to check: cron jobs, backups, queue workers, ETL pipelines and scheduled CI workflows.

Opsgenie shuts down on April 5, 2027, heartbeats included. Each heartbeat becomes a healthcheck with the same interval, and its ping URL replaces the Opsgenie ping in your job. One difference: a missed run alerts every channel at once instead of paging your on-call schedule, so route healthcheck alerts to PagerDuty if someone must be woken up. The Opsgenie migration guide has a script that recreates them all.

Ping only when the job succeeds: in a shell, chain the request after the command with &&, and in code, call the URL after the work is done. A job that crashes, exits with an error or never starts then sends nothing, and Hyperping alerts you once the grace period passes. Hyperping doesn’t store the job’s exit code or output, so keep your logs for the why.

It’s how long Hyperping waits after the expected run time before alerting. A backup scheduled at 2:00 with a 30-minute grace period can ping until 2:30. Set it a little above the job’s usual duration so slow runs don’t page anyone. It starts at 1 minute and defaults to 10 minutes in the dashboard.

Yes. In cron mode, give a healthcheck the job’s five-field expression, such as 0 9 * * 1-5, and its timezone, such as America/New_York. Hyperping computes each expected run from them, so weekends without runs don’t alert and daylight saving changes are handled. Build or check an expression with the cron expression generator.

Yes. Ping the URL with /start appended when the job begins, and the plain URL when it ends. The healthcheck’s history shows each run’s duration, along with the time, IP address, method and user agent of every ping. A run that starts but never finishes misses its deadline and alerts like a missed run.

Yes. Anything that can make an HTTP request can ping a healthcheck: curl or wget in a crontab, a systemd timer or a Kubernetes CronJob, a step at the end of a GitHub Actions or GitLab CI workflow, Invoke-WebRequest in a Windows scheduled task, or a request from your code in a Laravel, Rails, Django or Node.js scheduler.

Uptime monitoring checks a service from the outside: Hyperping calls your website or API as often as every 30 seconds and alerts when it stops answering. Cron job monitoring works the other way around: your job calls Hyperping, and silence is the failure. Most teams need both, and Hyperping runs them side by side. See uptime monitoring.

Healthchecks are included on every plan, the Free plan too. Each healthcheck counts as one of the plan’s monitors: 20 on Free, 50 on Essentials, 250 on Pro and 1,000 on Business, shared with your uptime checks. See pricing.

Cronitor goes deeper into job analytics and Healthchecks.io is open source and free to self-host. Hyperping keeps cron monitoring next to uptime checks, status pages and incidents in one account. See Hyperping vs. Cronitor and Hyperping vs. Healthchecks.io, or every tool side by side in the best cron job monitoring tools.