Email cron job errors with MAILTO

Set MAILTO in the crontab to choose who receives unredirected job output. Cron normally decides whether to send mail from the presence of output, not from the command's exit status. For failure-only messages, make a wrapper check the result explicitly.

Set a recipient

MAILTO="ops@example.com"
0 3 * * * /opt/jobs/backup.sh

The assignment applies to following jobs until another MAILTO setting changes it. With no explicit recipient, cron commonly mails the table's owner. MAILTO="" disables mail. Put comments on separate lines; a trailing comment on an environment assignment can become part of its value.

The host needs a working sendmail-compatible mail transport. Installing Postfix or a configured lightweight relay such as msmtp can provide one, but package installation is not proof that delivery works. Test from the job account and inspect relay logs, authentication, TLS, provider restrictions and spam handling if mail does not arrive.

Distinguish stderr from failure

This keeps normal output in a log while leaving standard error available for cron mail:

MAILTO="ops@example.com"
0 3 * * * /opt/jobs/backup.sh >> /var/log/jobs/backup.log

It is useful when the program consistently reports problems to stderr. It is not a strict failure filter: programs can write warnings to stderr and exit successfully, or fail without printing anything.

Send a summary on nonzero exit

Put the following logic in an executable wrapper such as /opt/jobs/backup-with-alert.sh. Provision the log directory for its account first:

#!/bin/sh
/opt/jobs/backup.sh >> /var/log/jobs/backup.log 2>&1
status=$?
if [ "$status" -ne 0 ]; then
    printf 'Backup failed on %s: exit status %s. See /var/log/jobs/backup.log\n' \
        "$(hostname)" "$status" >&2
fi
exit "$status"

Schedule that wrapper with MAILTO set and without redirecting its summary away:

MAILTO="ops@example.com"
0 3 * * * /opt/jobs/backup-with-alert.sh

A successful silent wrapper sends no mail; a failed command emits a short summary. Failure to open the log also produces an error. Keep the detailed output in the log, and test both success and failure paths. A killed wrapper or host outage still needs an external missed-completion check.

Make alerts useful

Use a job name, host, run identifier and status so the recipient can locate the relevant output. Avoid sending credentials or unlimited log contents by email. A custom subject generally requires invoking a suitable mail client yourself; MAILTO alone does not standardize subject formatting.

For several hosts, central log collection can retain the execution history while mail points to a particular failure. Verify ingestion and delivery independently.

Common questions

Can I specify more than one recipient? Debian cron documents a comma-separated list. Check your implementation and mail transport; a maintained mail alias is another option.

Why do successful runs generate email? They produced unredirected output. Cron does not assume that output means failure.

Why does a failed job generate no email? It may be silent, have all output redirected, have mail disabled, or encounter a delivery problem. Inspect the exit status and local mail logs separately.

References

• Debian crontab syntax
• Debian cron daemon behavior