Tired of useless two-sentence emails from your servers? Learn how to silence cron job spam the right way, from quick fixes to permanent architectural solutions.

I Don’t Care About Your SEO, and My Server Doesn’t Care About Yours Either

I remember it like it was yesterday. 3:17 AM. My phone lights up the room, buzzing like an angry hornet on my nightstand. It’s PagerDuty. The alert says “High volume of outbound mail from prod-db-01”. My heart sinks. Is the database server compromised? Is it part of a botnet? I stumble to my desk, VPN in, and start digging through mail logs. After twenty minutes of frantic searching, I find the culprit: a newly-added cron job to rotate a specific application log. The script was working perfectly, but it printed “Log rotation complete.” to the console on success. Every. Single. Hour. And our system was configured to treat any output from a cron job as an email to root, which then forwarded to our main ops alert address. We were DDoSing ourselves with success messages.

So, Why Is My Server Emailing Me In the First Place?

This isn’t a bug; it’s a feature—a really old one. By default, Unix and Linux systems are designed to be helpful. The `cron` daemon, the service that runs your scheduled tasks, will capture any output a script generates (both standard output and standard error) and dutifully email it to the user who owns the crontab. In most server setups, this defaults to the `root` user. That `root` account is often configured to forward its mail to a real person’s email address. So, any script that prints “Done”, “Success”, or even just an empty line will trigger an email.

While well-intentioned, in a modern cloud environment with proper logging and monitoring, this just becomes noise. Let’s shut it down.

The Fixes: From Duct Tape to a Real Solution

I’ve seen this problem tackled in a few ways. Here are the three main approaches, from the one you do in a panic to the one you put in your Terraform modules.

Solution 1: The Quick and Dirty Fix (The Muzzle)

This is the fastest way to shut a noisy cron job up. You just tell it to throw all of its output, both good and bad, into the digital void of `/dev/null`. You’ll see this everywhere on Stack Overflow.

Let’s say your noisy cron job looks like this:

0 * * * * /usr/local/bin/run_seo_check.sh

To silence it, you append `> /dev/null 2>&1`:

0 * * * * /usr/local/bin/run_seo_check.sh > /dev/null 2>&1

What’s happening here?

• > /dev/null redirects standard output (stdout) to nowhere.
• 2>&1 redirects standard error (stderr) to the same place as standard output.

Warning: This is a “hacky” fix for a reason. While it stops the spam, it also completely blinds you. If that script fails with a legitimate error, you will never know because you’ve thrown the error message away. Use this only for scripts you know are non-critical or that have their own internal logging mechanisms.

Solution 2: The Permanent Fix (The Right Way)

The much cleaner, more intentional way to handle this is to tell `cron` itself who to email, or in this case, who not to email. You do this by setting the `MAILTO` variable at the top of your crontab file.

You can edit the crontab by running `crontab -e`. Then, add this line to the very top:

MAILTO=""

# Keep cron jobs below this line
0 * * * * /usr/local/bin/run_seo_check.sh
15 2 * * * /opt/scripts/backup.sh

By setting `MAILTO` to an empty string, you’re telling the cron daemon, “Don’t bother emailing anyone, ever, for any of the jobs in this file.” This is the globally preferred method. It stops the email behavior at the source without suppressing potentially valuable error output. If you want to debug a script, you can just SSH into the box and run it manually to see its output.

Pro Tip: A better architecture is to have your scripts log to `stdout`/`stderr` and have your log forwarder (like Fluentd or a CloudWatch Agent) ship those logs to a central location. Let cron be a scheduler, not a notification service. Set `MAILTO=””` and rely on your centralized logging and monitoring for alerts.

Solution 3: The ‘Nuke It From Orbit’ Option

In some cases, you might not even want a mail transfer agent (MTA) like `postfix` or `sendmail` running on the server at all. This is common in immutable infrastructure, containerized environments, or highly-secured servers where you want to minimize the attack surface.

The approach here is to either uninstall the MTA or stop and disable it completely.

For a system using `systemd` (most modern Linux distros):

# Stop the service for the current session
sudo systemctl stop postfix

# Disable it from starting on boot
sudo systemctl disable postfix

This is the most drastic option. It ensures the server physically cannot send any email, which might be exactly what you want. The downside is that if any other system-level process legitimately needs to send mail, it will fail. This is an architectural decision, not just a quick fix.

Comparison of Solutions

So next time you get a pointless two-sentence email from a server, don’t just add `> /dev/null 2>&1` and call it a day. Take a moment, use `MAILTO=””`, and be the senior engineer who fixes the problem, not just the symptom.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions