Fix "Cron No MTA Installed, Discarding Output"

What "No MTA Installed, Discarding Output" Actually Means

If you've been digging through /var/log/syslog or run journalctl -t CRON and spotted a line like:

CRON[12345]: (CRON) info (No MTA installed, discarding output)

you're looking at a routine informational message, not an error. Cron tried to email the output of a job it just ran, found no Mail Transfer Agent (MTA) on the system to hand that email to, and dropped it. Postfix, Exim, and sSMTP are all examples of MTAs — none is installed by default, so cron has nowhere to send the message.

This is a cron info message, not a failure code. The job itself almost certainly ran and finished — cron is only complaining about what to do with the text it printed to stdout or stderr afterward. If your script exited cleanly and produced output (even a harmless log line or a warning), you'll see this exact message. Check your job's actual exit status and logs before assuming anything is broken.

Why It Shows Up (and Why It's Not a Cron Bug)

This message is nearly universal on minimal server images. Ubuntu and Debian cloud images, and virtually every Docker base image, ship without any mail service installed — there's no reason to bundle an MTA on a server that isn't running its own mail infrastructure. That's a deliberate design choice to keep images small, not an oversight.

Meanwhile, cron's default mail behavior hasn't changed in decades: any time a cron job writes to stdout or stderr, cron tries to email that output to the crontab owner (or whatever address MAILTO specifies). This was sensible in an era when every Unix box ran a local mail server. On a modern cloud VM or container, there's no mail service listening, so the moment a job prints so much as a single line, cron's attempted delivery has nowhere to go — and you get this message logged instead.

In short: no MTA installed is the normal state on Ubuntu, Debian, or your container image, and cron trying to email stdout/stderr output is normal cron behavior. The combination produces this log line by design, every time a job talks.

3 Ways to Fix or Silence It

You have three practical options, and which one fits depends on whether you actually want that output somewhere.

1. Install a lightweight MTA and configure local delivery. If you want cron mail to actually work, install Postfix (the most common choice) or a lighter alternative like sSMTP or msmtp:

sudo apt update && sudo apt install postfix

During setup, choose "Local only" unless you're relaying through an external SMTP provider. Mail will now deliver to the local user's mailbox, readable with mail or mailx. This is the standard fix for installing Postfix for cron email on Debian/Ubuntu, and it's covered in more depth in Cronitor's guide to this exact message.

2. Redirect job output to a log file instead of letting cron mail it. This avoids the MTA question entirely. Append output redirection directly in the crontab line:

0 * * * * /path/to/script.sh >> /var/log/script.log 2>&1

Now stdout and stderr both land in a plain file you can tail or ship to a log aggregator — no mail system involved. This is usually the cleanest option for redirecting cron output to a file rather than fighting with mail delivery.

3. Suppress it entirely. If you don't want the output anywhere, set an empty MAILTO at the top of the crontab:

MAILTO=""

Or discard output per-job:

0 * * * * /path/to/script.sh >/dev/null 2>&1

Either approach stops cron from ever attempting delivery, and the log message disappears for good.

Should You Even Bother Installing an MTA?

For a personal script or a one-off cleanup task, no — suppressing the message with MAILTO="" or /dev/null redirection is perfectly reasonable. You don't need a mail server running just to quiet a log line for a job nobody's watching closely.

For anything business-critical, though, it's worth asking a harder question: is cron mail a good alert system in the first place? Even with a correctly configured MTA, local mail delivery is notoriously unreliable outside a proper mail infrastructure. Messages routed through a freshly configured Postfix instance frequently get flagged as spam, rejected by receiving servers with strict SPF/DKIM checks, or simply pile up in a mailbox nobody reads. Relying on cron email as your only failure signal for something a customer or team depends on is a gamble, not a monitoring strategy.

A Better Long-Term Fix: Stop Depending on Cron Mail for Failure Alerts

Here's the catch with every fix above: once you install an MTA that quietly fails to deliver, redirect output to a file nobody watches, or suppress output completely, you've lost your only signal that a job failed. Silence becomes indistinguishable from success. That's the real problem hiding behind this error message — not the log line itself, but what you do after making it go away.

Cron job monitoring built for HTTP pings solves this directly. Instead of cron trying (and often failing) to mail you output, your script sends a lightweight HTTP ping when a job starts, finishes, or fails — no local mail system required. Cronevra — Cron jobs that never fail silently. tracks those pings, expects them on schedule, and alerts your team the moment a job misses its run, errors out, or takes too long — through channels people actually check, not a mailbox on a server nobody logs into.

This is a materially different approach from cron failure alerts via email: no MTA to configure, no spam filters to fight, no dependence on the very mail infrastructure that caused the original error message. You get a real dashboard of execution history and failures instead of a scattering of log lines across syslog and journalctl.

Frequently Asked Questions

Is 'No MTA installed, discarding output' a sign my cron job failed?

No, it's an informational message about mail delivery, not a job failure indicator. Cron logs this whenever a job produces output but no mail agent exists to send it — the job itself typically completed and exited normally. Check the job's actual exit code or application logs to confirm success or failure.

Do I need to install an MTA just to get rid of this message?

No, installing an MTA is only one of three options. You can instead redirect output to a file with >> logfile 2>&1, or suppress it entirely with MAILTO="" or /dev/null redirection — both are simpler if you don't need email delivery.

What's the easiest way to stop cron from trying to send email at all?

Set MAILTO="" at the top of your crontab, or append >/dev/null 2>&1 to individual job lines. Both immediately stop cron from attempting delivery, which eliminates the log message without touching mail infrastructure.

Why don't I see this message on some servers but see it on others?

It depends on whether an MTA is installed and whether your jobs actually produce output. Minimal images like fresh Ubuntu, Debian, or Docker base images ship with no mail service by default, so any job that prints text triggers the message; servers with Postfix or Exim already configured won't show it.

Does installing Postfix fix this permanently, or do I need extra configuration?

Installing Postfix stops the "no MTA" message, but you typically still need to configure it — choosing "Local only" mode for basic delivery, or relay settings if you want mail to leave the server. Without correct configuration, mail can still fail silently or get flagged as spam, so it's not a guaranteed permanent fix.

Is there a way to know if my cron job failed without relying on cron email at all?

Yes — HTTP-based monitoring tools like Cronevra let your job ping an endpoint on start, success, or failure, independent of any local mail system. This gives you reliable failure and latency alerts even on servers with no MTA installed at all.

Once you suppress or redirect that output, your team loses visibility into failures the moment they happen — which defeats the purpose of running the job in the first place. Add a Cronevra HTTP ping to your existing cron jobs and get failure and latency alerts within minutes, no mail server required. Check the pricing page to see which plan fits your team.