Dead man’s switch

Heartbeat Monitoring for Cron Jobs & Background Tasks

CronJobPro's dead-man's-switch monitoring detects when a job stops running — even when it produces no error. Get alerted the moment a backup, scraper, ETL pipeline, or queue worker goes silent.

Start monitoring free

Most monitoring tools watch for failures that make noise: a server that returns 500, a service that goes down, a deploy that throws an exception. But some of the most damaging failures are silent — a nightly backup that quietly stops running, a data pipeline that never starts, a queue worker that freezes without logging a thing. CronJobPro's heartbeat monitoring solves exactly this problem. Instead of CronJobPro reaching out to your job, your job reaches out to CronJobPro. If the expected check-in never arrives, you get alerted. This is the dead-man's-switch model: the alarm fires not because something went wrong, but because something went quiet.

# Add one line to the end of your job — ping on success:
curl -fsS https://cronjobpro.com/ping/<your-token>

# Or report an explicit failure / exit code:
curl -fsS https://cronjobpro.com/ping/<your-token>/fail
my_job && curl -fsS https://cronjobpro.com/ping/<your-token>/exitcode/$?

What Is Heartbeat Monitoring?

A heartbeat monitor is the inverse of an uptime check. With uptime monitoring, CronJobPro polls your URL to confirm it responds. With heartbeat monitoring, your script or process pings CronJobPro to confirm it ran. You set an expected period — say, every 24 hours — plus a grace window to allow for minor scheduling drift. If a ping does not arrive within that window, CronJobPro treats the silence as a failure and fires your configured alerts. This pattern is also called a dead-man's switch: the system stays quiet only as long as the job keeps checking in. The moment a job misses its window, the switch trips.

  • Detects silent failures: missed runs, frozen workers, crashed daemons
  • Works with any job that can make an HTTP request — shell scripts, Python, Node.js, CI pipelines, IoT devices
  • No agent to install; the only requirement is a single HTTP call from your process

How It Works: The Ping URL

When you create a heartbeat monitor in CronJobPro, you receive a unique ping URL in the form https://cronjobpro.com/ping/<token>. Add a call to that URL at the end of your job — when it completes successfully. CronJobPro records the timestamp and resets the countdown. If the next expected ping does not arrive before the period plus grace window elapses, the monitor enters a failing state and sends your alerts. You also have two additional endpoints for richer signal:

  • GET /ping/<token> — signals a successful run; resets the timer
  • GET /ping/<token>/fail — explicitly signals a failure; useful when your script detects an error and wants to alert immediately rather than waiting for the window to expire
  • GET /ping/<token>/exitcode/<n> — reports the numeric exit code of your process; exit code 0 is treated as success, any other value as failure

Heartbeat Monitoring vs. Uptime Monitoring

These two monitoring modes answer different questions and complement each other. Uptime monitoring is pull-based: CronJobPro sends an HTTP request to your URL on a schedule and checks for a 2xx response. It is ideal for websites, APIs, and services that are always supposed to be reachable. Heartbeat monitoring is push-based: your job sends a signal to CronJobPro when it completes. It is designed for processes that run on a schedule and then stop — backups, batch jobs, data imports, report generators. A job that runs on your own server and exits cleanly cannot be monitored by an uptime check. A heartbeat monitor is the right tool because it watches for the presence of activity rather than the availability of an endpoint.

  • Uptime check: CronJobPro pings you — detects downtime and slow responses
  • Heartbeat monitor: you ping CronJobPro — detects missed, late, or silently failed runs
  • Use both together for full coverage of services and scheduled tasks

What You Can Monitor

Any repeating process that can make an HTTP request is a candidate for a heartbeat monitor. The pattern is especially valuable for jobs that run outside CronJobPro's own scheduler — on your own servers, in CI, on embedded devices, or inside containers you manage.

  • Database and file system backups — confirm your nightly backup actually completed
  • Web scrapers and data collectors — know immediately when a scraper stops producing data
  • ETL pipelines and data imports — detect stalled or missing data pipeline runs
  • Queue workers and consumers — alert when a worker stops processing jobs
  • CI/CD pipeline steps — verify post-deploy scripts, test runners, or artifact uploads ran
  • IoT devices and remote scripts — monitor embedded systems or edge devices that report in on a schedule
  • Any shell script, Python script, or background service running on your own infrastructure

Alerting Channels

When a heartbeat monitor fails — meaning the expected ping did not arrive in time, or a /fail or non-zero /exitcode ping was received — CronJobPro sends alerts through whichever notification channels you have configured. The same channels that handle alerts for your scheduled HTTP cron jobs apply to heartbeat monitors, giving you a single unified notification system across all your monitoring. You can also configure an alert threshold to suppress notifications until a monitor has failed a set number of consecutive times, reducing noise for jobs with occasional timing variance.

  • Email
  • Slack
  • Discord
  • Microsoft Teams
  • PagerDuty
  • Opsgenie
  • Webhook (HTTP POST to any endpoint you specify)

Getting Started in Three Steps

Setting up a heartbeat monitor takes under a minute. No agents, no SDKs, no infrastructure changes beyond adding one line to your existing script.

  • 1. Create a heartbeat monitor in your CronJobPro dashboard — set the expected period and grace window, and attach your notification channels
  • 2. Copy the generated ping URL and add it to the end of your job: curl -s https://cronjobpro.com/ping/<token> (or the equivalent in your language)
  • 3. Run your job once to confirm the first ping is received — the monitor status will turn healthy and the countdown begins

How CronJobPro Checks Your Monitors

The CronJobPro watchdog evaluates heartbeat monitors approximately every 30 seconds. When a monitor is first created or receives its first ping, a warm-up period of 120 seconds applies before the monitor can enter a failing state — this prevents false alerts immediately after setup. Once active, any monitor that exceeds its period plus grace window without a successful ping will transition to failing and trigger your configured alerts. When a successful ping arrives after a failure, the monitor recovers and a recovery alert is sent, so you know when the job is healthy again.

Frequently asked questions

What is the difference between a heartbeat monitor and an uptime check?

An uptime check is pull-based: CronJobPro periodically sends a request to your URL and checks for a 2xx response. It is suited for always-on services. A heartbeat monitor is push-based: your job sends a ping to CronJobPro when it completes. It is suited for scheduled tasks that run and exit — the alert fires when the expected ping does not arrive, meaning the job missed its run or ran but failed. The two modes are complementary: use uptime checks for services, heartbeat monitors for batch jobs.

Does my job need to run on CronJobPro's scheduler to use heartbeat monitoring?

No. Heartbeat monitoring is entirely independent of where or how your job is scheduled. Your job can run on your own server's cron, inside a CI pipeline, on a Docker container, on a Raspberry Pi, or anywhere else that can make an outbound HTTPS request. CronJobPro only needs to receive the ping — it does not need to be the scheduler.

What happens if my job fails before it can send the success ping?

If your job crashes or exits with an error before reaching the ping call, the success ping is never sent and the monitor will eventually expire its window and alert you. For faster alerting, you can also call the /ping/<token>/fail endpoint explicitly in your error-handling code, or use /ping/<token>/exitcode/<n> to report the process exit code. This lets CronJobPro alert immediately rather than waiting for the full period plus grace window to elapse.

How do I set the period and grace window?

The period is how often you expect your job to run — for example, 1 day for a nightly backup. The grace window is additional time allowed beyond the period before CronJobPro considers the monitor failed, to account for slight scheduling delays or slow jobs. A job scheduled every hour might get a 10-minute grace window. The alert fires only after period plus grace window have passed without a successful ping.

Can I suppress alerts for occasional late pings?

Yes. CronJobPro supports an alert threshold setting that delays notifications until a monitor has failed a configured number of consecutive times. This is useful for jobs with occasional timing variance where a single missed window is not worth waking someone up. When the threshold is set to 3, for example, you will only be alerted after three consecutive missed windows — not the first one.

Catch silent failures before they cost you

Add one HTTP call to your job and let CronJobPro alert you the moment it goes quiet.

Start freeRead the guide
Heartbeat Monitoring (Dead Man’s Switch) for Cron Jobs | CronJobPro