Learning Cron Job - Output, Mail & Logging

#Introduction

In episode 4 we could write schedules. The next question: where does job output go? A single echo "backup selesai" line in crontab — who will see it?

Cron has a default behavior that often surprises people: output that isn't redirected anywhere gets collected and sent via email. On servers without an MTA (Mail Transfer Agent), that email just piles up in the mail spool and fills the disk. This episode covers how cron handles output, and proper logging practices so you don't lose track of your jobs.

#Cron Output: Default Behavior

When a command in crontab produces output (stdout or stderr) and isn't redirected, crond collects it and sends it as email to the crontab owner — or to the address in the MAILTO variable.

MAILTO=admin@example.com

Any output (including errors) from a job is sent to that address. If MAILTO isn't set, email goes to the crontab owner's user.

#The Problem: Without an MTA, Email Piles Up

Modern servers often lack a full MTA. With no way to deliver, cron writes the mail to the local spool:

/var/spool/mail/<username>

This file can silently balloon, filling the disk. Check it with:

ls -lh /var/spool/mail/

#Redirecting Output to a Log

The most common and most recommended solution: point output at a log file so you don't depend on email at all.

#Appending to a Log: > vs >>

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

• >> appends to the end of the file — don't use >, which overwrites.
• 2>&1 merges stderr into stdout, so errors also land in the log.

#Per-Job Logs

A best practice we'll use throughout the series: one log file per job, clearly named:

/var/log/backup.log
/var/log/cleanup.log
/var/log/healthcheck.log

The benefits: easy to inspect (tail -f /var/log/backup.log), easy to rotate, and no mixing of queues.

#/var/log/cron: Cron Activity Log

Besides per-job logs, cronie records its own activity to syslog, usually at /var/log/cron:

grep CRON /var/log/cron | tail -20

Its output records one line per execution:

Aug 13 02:30:01 host CROND[1234]: (root) CMD ( /usr/local/bin/backup.sh )

This log is the primary debugging source: from here you can see whether a job ran, when, and as which user.

#Logrotate: Don't Let Logs Balloon

Logs that keep growing eventually fill the disk — ironic for a tool meant to prevent that. Rotate logs periodically with logrotate, whose own schedule is managed via cron:

/var/log/backup.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
}

The config above rotates the log daily, keeps 14 histories, and compresses them. We'll cover logrotate in more depth in episode 10.

#Recommended Logging Pattern

The complete pattern for a production job:

SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
MAILTO=""
 
30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

With this pattern:

• No email piling up (MAILTO="").
• All traces live in one time-indexed log file.
• Logs can be rotated and monitored.

#Closing

Key takeaways:

• Cron output without redirect is emailed to MAILTO.
• Without an MTA, email piles up in /var/spool/mail/ and fills the disk.
• Redirect with >> /var/log/<job>.log 2>&1 — append, not overwrite.
• Use one log file per job with a clear name.
• /var/log/cron records job executions — the primary debugging source.
• Rotate logs with logrotate so they don't balloon.

In episode 6 we'll cover environment and PATH in cron — why scripts that run perfectly in your terminal get "command not found" in crontab, how cron uses /bin/sh with a short PATH, and how to fix it with SHELL, PATH, and HOME. This is one of the most common mysteries in the world of cron!