Stop cron job emails flooding your inbox (the real fix)

You know the pain

You check your inbox and there it is — 47 emails from your server's cron jobs. Every one of them says something like "Disk usage: 42% used" or just a blank line. Your inbox is full of noise, and the real alerts get buried.

The fix: redirect cron output to /dev/null

This is the quickest way to stop the flood. Open your crontab with crontab -e and add >/dev/null 2>&1 at the end of each job line. Like this:

0 * * * * /usr/bin/df -h >/dev/null 2>&1

What this does: it throws away all output (stdout) and all error messages (stderr). The job still runs, but nothing gets mailed to you.

I had a client last month whose mail server was choking on 2,000 cron emails a day from a simple monitoring script. One edit to the crontab and the server stopped crying.

Why cron sends emails at all

Cron by default sends any output from a job to the user's local mailbox — usually /var/mail/username. If your system is forwarding that mail to your real inbox (like via Postfix or sendmail), you get flooded.

It's a design from the old days when sysadmins lived on the same machine. Today, it's mostly a nuisance unless you're tracking down a script error.

Keep errors but silence success

If you still want to know when something breaks, redirect only the success output. Use this:

0 * * * * /usr/bin/df -h 2>&1 | grep -q "error" || echo ""

Or simpler — send stdout to /dev/null but let stderr come through:

0 * * * * /usr/bin/df -h >/dev/null

That way, only errors get mailed. If your script runs clean, you get nothing. This is how I set up monitoring jobs for a logistics company that couldn't afford false alarms.

Less common scenarios that trip people up

1. MAILTO in the crontab

You can add MAILTO= at the top of your crontab to turn off all emails:

MAILTO=""
0 * * * * /usr/bin/df -h

But this only works if your system's MTA is configured to honor an empty MAILTO. Some setups (like systems using bsd-mailx or older sendmail) ignore it. If you set MAILTO to empty and still get mail, use the redirection method above instead.

2. Cron jobs that run as root

If you're editing root's crontab (sudo crontab -e), the output goes to root's mailbox. That's often /var/mail/root. If you have mail forwarding set up for root, it still ends up in your inbox. Use the same redirection. I've seen this cause confusion — root's mail flows to a different place than regular user's mail.

3. System-wide cron scripts in /etc/cron.d

Scripts placed in /etc/cron.d/ also generate emails. You can add MAILTO= in the script file or wrap the command with redirection inside the script itself. Don't forget — these run as a specific user, so the mail goes to that user's mailbox unless you change it.

4. Cron jobs that generate huge output

Sometimes a script produces megabytes of logs per run. Redirecting to /dev/null wastes data you might need later. Better approach — pipe output to a log file with a timestamp:

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

Then check the log only when something smells wrong. I set this up for a dental practice's nightly backup — saved them from digging through 300 daily emails.

5. Using logger instead of mail

If you want cron output to go to syslog instead of mail, replace the command with logger:

0 * * * * /usr/bin/df -h | logger -t crondf

Then check /var/log/syslog or journalctl. This keeps a record without filling your inbox. It's what I use for all my own servers now.

How to prevent this from happening again

• Check your crontab every month. Look for jobs that don't have output redirection. Add it. Simple.
• Use a log rotation policy. If you log to files, set up logrotate so logs don't eat up disk space.
• Test new cron jobs silently. Before adding a new job to production, run it manually with >/dev/null 2>&1 first. If it works, add it to crontab the same way.
• Don't rely on cron for critical alerts. Use a proper monitoring tool like Nagios, Zabbix, or a cloud service. Cron emails are too easy to ignore.

One more thing — if you're running a mail server that's being hammered by cron emails, also check your mail logs. I've seen Postfix queues fill up with undeliverable cron mail because the recipient's inbox was full. That's a cascading failure you don't want. Fix the cron output, and your mail server stays happy.

That's it. You're not getting any more cron spam. Now go fix that crontab.