Know When Your Cron Jobs Stop Running

Why cron jobs need their own monitoring signal

Website uptime checks do not prove that a nightly import, cleanup script or backup task ran. A cron daemon can be disabled, a machine can be offline, a dependency can fail, or the script can exit before it reaches its final step.

The heartbeat pattern puts the report inside the job. Send it only after the work has reached the point you consider successful. In a shell script, that commonly means chaining the report with &&, not placing it after an unconditional separator.

/path/to/job.sh && curl --fail --silent --show-error https://heartbeathook.example/heartbeat/create

The example shows the sequencing idea only. The current HeartbeatHook endpoint requires the full authenticated JSON and HMAC contract described in the API reference.

Failure modes a heartbeat can expose

• the scheduler never starts the job;
• the machine or container is unavailable;
• the script fails on a dependency, permission or storage error;
• the process exits before its completion checkpoint;
• the job continues running but cannot reach the monitoring service.

Cron monitoring is not website monitoring

Website monitoring asks whether a public service responds. Cron monitoring asks whether expected work was executed and reported. A useful setup often uses both: an external check for the public application and an outbound heartbeat for scheduled work.

Where HeartbeatHook fits

HeartbeatHook provides the authenticated receiving side for application heartbeats. It does not schedule cron jobs and it does not currently advertise email, SMS or chat alerts. The operational response to a missing heartbeat belongs in the monitoring and incident workflow you choose around the API.