How to monitor cron jobs: setup, examples, and verification

1. Match the monitor to the real job

Record the schedule, timezone, and normal completion time. Use one monitor per non-overlapping workload. Two independent jobs sharing a URL can hide each other’s failures. Choose grace for legitimate runtime and scheduler delay; do not use a large grace period simply to silence unexplained alerts.

Create an interval monitor manually, review supported configuration in Cron Doctor, or discover a connected GitHub repository’s workflows. A new monitor waits for installation and its first receipt. For daily or weekly work, that first scheduled run may be a long way away.

2. Send success after successful work

Replace YOUR_MONITOR_SUCCESS_URL with the actual URL shown by your monitor. Keep it private. Each example below is one crontab line; do not split it across physical lines. Use absolute paths, ensure the job exits nonzero on failure, and place the heartbeat before any trailing cron comment.

0 2 * * * /scripts/backup.sh && curl --max-time 10 -fsS YOUR_MONITOR_SUCCESS_URL

0 2 * * * /opt/app/.venv/bin/python /opt/app/job.py && curl --max-time 10 -fsS YOUR_MONITOR_SUCCESS_URL

0 2 * * * /usr/bin/node /opt/app/job.js && curl --max-time 10 -fsS YOUR_MONITOR_SUCCESS_URL

The shell’s && runs curl only if the workload exits successfully. If the application swallows errors and exits zero, this can report success incorrectly. Put the heartbeat after your own output checks when meaningful completion differs from process exit.

Optional start and failure signals

For a more explicit integration, run this wrapper from cron after replacing the workload path. The heartbeat calls have time limits. A telemetry error stays visible on standard error but does not skip the workload, replace its exit code, or turn a failed success request into a workload-failure report.

#!/bin/sh
# Supply the actual monitor URL through your job environment.
: "${PINGCRON_URL:?Set the monitor success URL}"
curl --max-time 10 -fsS "$PINGCRON_URL/start" >/dev/null || :
if /path/to/your-job; then
  curl --max-time 10 -fsS "$PINGCRON_URL" >/dev/null || :
else
  job_status=$?
  curl --max-time 10 -fsS "$PINGCRON_URL/fail" >/dev/null || :
  exit "$job_status"
fi

A start receipt does not prove success. In PingCron, a started run must finish within grace, or an earlier scheduled deadline if one applies. Repeated starts do not extend that deadline. Concurrent executions need separate monitors; this pattern does not correlate overlapping runs by run ID.

3. Verify the first run and the alert destination

1. Save your email or other eligible alert destination in Settings, send a labeled test, and confirm receipt.
2. Run the actual job through its scheduler. Check its output and confirm a successful heartbeat in the monitor’s history.
3. Use an isolated test job to exercise a missed run and recovery. Check both the monitor state and the delivery history, then pause the disposable monitor.

Provider acceptance is not inbox delivery. A heartbeat is not proof of data correctness. For backups, keep independent restore drills; for data pipelines, validate the rows or outputs that matter.

Cron job not running? Work through these checks

• Schedule: check the cron fields and scheduler timezone with the crontab validator. Account for daylight-saving transitions.
• Execution context: verify the scheduler is enabled, the right user owns the job, and paths, permissions, environment variables, and credentials exist in the scheduled environment.
• Workload: inspect its logs and exit status. A successful launcher may only have queued work elsewhere.
• Heartbeat: confirm the URL belongs to this monitor, outbound HTTPS works, and the success call executes only after required work.
• Alerts: check whether the monitor has received its first check-in, is paused, or is still within grace. Review saved destinations and delivery attempts.