Cron & Task Scheduling (Cron/Systemd Timers/At)

Stop ignoring the silence when your crontab job dies

🧩 The Challenge

You’ve got a backup script that runs at 3 AM and for weeks everything is fine until one day the database dumps are empty and you have zero clue when it actually stopped working. Cron is a silent killer because it just eats standard error and assumes you don’t want to be bothered unless the mail spool is configured perfectly.

💡 The Fix

Pipe both stdout and stderr into a log file or a mail command so you finally get some visibility into those middle-of-the-night crashes. If the command fails, you’ll have a permanent record of the exit code and the actual error message waiting for you in the morning.

0 3 * * * /usr/local/bin/backup.sh > /var/log/backup.log 2>&1

⚙️ Why It Works

Redirecting the file descriptor 2 to 1 merges the error stream into the standard output stream, forcing cron to handle them both as one single log target. Without this explicit redirection, cron usually discards everything but the absolute bare minimum output.

🚀 Pro-Tip: Toss an ‘exit 1’ at the end of your script logic if a database check fails so you get a non-zero return code recorded in your logs.

Linux Tips & Tricks | © ngelinux.com | 9/27/2026