How to Get Alerted When a Cron Backup Job Fails or Stops Running

A cron backup runs on a schedule set by the Unix cron service. If the backup command exits with an error, the job never starts, or it hangs, a notification generated only by that command may not reach you. An external monitor addresses the missed-run problem by waiting for a check-in, also called a heartbeat, from the job.

For dependable coverage, send that heartbeat only after the backup passes its required checks. Add an immediate failure signal when the command exits unsuccessfully, and a start signal if you want an alert when a run takes too long. A missed heartbeat tells you that the check-in did not arrive; it does not, by itself, explain whether the host, cron, backup, network, or monitor caused the problem.

Send a heartbeat only after a successful backup

Create a separate check for each scheduled backup in an external monitoring service. Set the check to expect the same schedule as cron, then have the job contact its unique ping URL after the backup completes successfully. The monitor alerts when the expected check-in is late or missing. Because the monitor runs outside the backup host, it can also detect a host outage or stopped cron service, as long as the monitor and alert route remain reachable.

For example, Healthchecks.io documents this daily cron entry:

8 6 * * * /home/me/backup.sh && curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/your-uuid-here

The && operator runs the ping only if the backup command exits with status 0. The curl options limit the request to 10 seconds and retry failed requests up to five times. They also treat an unsuccessful HTTP response as an error and discard the response body. Replace the example script path and ping URL with your own values. See Healthchecks.io’s cron monitoring example.

Set the monitor’s expected schedule and time zone to match the server’s cron schedule. Set a grace period, the time the monitor waits after a check-in is due before alerting. Make it long enough for ordinary run-time variation, but short enough to alert before the delay becomes unacceptable. For example, Healthchecks.io describes a 30-minute grace period for a daily job expected to take 15 to 25 minutes. Use that as an example, not a universal setting. A time-zone mismatch can also make a check-in appear early or late.

Report failures and long runs directly

If a backup exits with an error, its success check-in never arrives, so the monitor alerts when the check-in is overdue. You can also report a nonzero exit status as soon as the command fails. That lets the monitor distinguish a command failure from a missed run. Add a start signal if you want the monitor to track how long the job takes. If no success signal arrives after the start, the monitor can alert when the allowed run time expires.

This Bash wrapper shows all three signals:

#!/usr/bin/env bash

PING_URL='https://hc-ping.com/your-uuid-here'

# Do not let a monitoring outage prevent the backup from starting.
curl -fsS -m 10 --retry 5 -o /dev/null "$PING_URL/start" || true

if /usr/local/bin/run-backup; then
    # Add required backup checks before sending success.
    curl -fsS -m 10 --retry 5 -o /dev/null "$PING_URL" || true
else
    rc=$?
    # Report the backup's exit status and preserve it as the wrapper's status.
    curl -fsS -m 10 --retry 5 -o /dev/null "$PING_URL/$rc" || true
    exit "$rc"
fi

Schedule the wrapper in cron in place of the direct backup command. The || true clauses make the monitoring requests best-effort: a failed ping does not stop the backup or replace its exit status. The scheduled missed-heartbeat alert remains a fallback if the success or failure signal cannot be delivered. Timeouts and retries reduce the chance that a brief network problem disrupts the job, but they do not guarantee delivery. Healthchecks.io documents start and exit-status signals in its shell-script guidance.

Choose the grace period to cover the longest legitimate run, including expected slowdowns. When a job sends a start signal, that period also sets how long the monitor waits for completion. With a short limit, the monitor catches hangs sooner but may alert during a valid long run. A longer limit gives the job more time to finish but delays notification of a real stall. Healthchecks.io explains this behavior in its script run-time documentation.

Treat cron email as a backup notification

On Linux systems covered by the crontab(5) manual, the MAILTO setting directs cron-generated mail to an address. For example:

MAILTO=ops@example.com
8 6 * * * /home/me/backup.sh

Cron mail reports job output, so it depends on the job producing output and on the host having working mail delivery. It does not independently alert you when the host is down, cron never launches the job, or the crontab is missing. Use it as a supplementary notification, not as the only way to detect a stopped backup. The Linux crontab manual documents the setting; behavior can vary across cron implementations and system configurations.

Check what the backup means by success

A successful command exit and heartbeat show that the job reported success. They do not prove that the backup captured every required file, that you can read the backup, or that you can restore from it. Make the heartbeat depend on the checks that matter for your recovery needs, then schedule integrity checks and test restores separately.

Backup tools also define exit statuses differently. For example, restic documents exit status 3 for a backup that created a snapshot but could not read some source data. A wrapper that treats every nonzero status as failure will report that condition; the operator must decide whether to handle it as a failure or classify it separately. Check your backup tool’s own documentation before interpreting its exit codes. The restic scripting documentation describes its behavior.

Keep the ping URL private because someone who obtains it can send signals to the check. Test both a deliberate backup failure and a missed check-in, then confirm that the intended recipients receive alerts. If a check-in is missing, inspect the host’s cron logs and the backup logs. On some systemd-based Linux hosts, journalctl --since "1 hour ago" -t CRON shows recent cron messages. Log tags and availability vary by system.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com