Cron job monitoring

Uptime checks poll something and interpret the answer. A scheduled job has nothing to poll: when it stops being scheduled, there is no failing request, no error page and no exception. The observable fact is that nothing happened, and nothing is hard to notice.

A heartbeat records a report when your job reaches it. PostDeploy currently records successful finishes and explicit failures. It does not evaluate a missing report against the schedule or grace period. Use an external scheduler watchdog when you need an alert for a decommissioned server, a disabled schedule, or a job that never reaches the reporting line.

Create a heartbeat monitor, copy its token, and append one curl call to your job. The && matters: it ties the ping to the job's exit status, so a failing backup never reports success.

The -f flag makes curl fail on an HTTP error, -s silences progress output, and -S still prints errors. Inside cron, where any output becomes mail, that combination is what you want.

# Ping only if the job succeeded.
0 3 * * * /usr/local/bin/backup.sh && curl -fsS https://ingest.postdeploy.dev/h/hb_YOUR_TOKEN

The one-liner above tells PostDeploy nothing when the job fails. To record a failure immediately, report the exit code instead. Append it as a path segment: 0 is a success, anything else is a failure that opens an incident right away, bypassing the failure threshold.

In a shell, $? holds the exit status of the previous command, so a single line covers both outcomes. Use ; rather than && here, because the ping has to run whether or not the job succeeded.

# 0 reports success, any other exit code opens an incident.
0 3 * * * /usr/local/bin/backup.sh; curl -fsS "https://ingest.postdeploy.dev/h/hb_YOUR_TOKEN/$?"

Send a start ping before work and a finish ping after it when you need both events in the check history. A ping with no state parameter is treated as a finish, so existing one-liners keep working unchanged.

A missing finish has no independent deadline evaluation. A later heartbeat can record a prior started run as hung when expected duration is configured, but that later request does not make an absent run detectable.

curl -fsS "https://ingest.postdeploy.dev/h/hb_YOUR_TOKEN?state=start"
/usr/local/bin/backup.sh
curl -fsS "https://ingest.postdeploy.dev/h/hb_YOUR_TOKEN?state=finish"

Send one request from the same environment that runs the job. A recognised heartbeat URL returns 202. A 404 means the token is wrong. If the request cannot connect, check the runner's outbound network access.

curl -i "https://ingest.postdeploy.dev/h/hb_YOUR_TOKEN"
# Expect: HTTP/1.1 202 Accepted

GET and POST behave identically, so wget, a fetch() call, or any HTTP client works exactly as curl does. Possession of the hb_ token is the authentication, so no header or API key is needed, and the URL should be treated as a secret.

A recognised token always returns 202, including when the monitor is paused, in which case nothing is recorded. An unrecognised token returns 404.