Crontab Logs: Where to Find Them and How to Debug Cron Jobs.

When a cron job misbehaves, the first question is always "did it even run?". Cron's own logs answer that; your job's output answers "and what happened?". They live in different places, and many systems keep only one of them by default.

Key takeaways

• Cron logs record that a job started; they don't contain the job's output.
• On Debian and Ubuntu look in /var/log/syslog or journalctl -u cron; on RHEL-family systems, /var/log/cron or journalctl -u crond.
• Redirect each job's stdout and stderr to its own log file.
• Add timestamps and exit codes so a log line tells the whole story.
• Logs show the past; a heartbeat monitor tells you when a run is missing right now.

Two kinds of cron logs

1. The daemon's log - one line each time cron starts a command: time, user and command. It proves the schedule fired.
2. The job's own output - whatever the command printed. Cron doesn't store it; without redirection it tries to email it, and on most servers that mail goes nowhere.

Where the daemon logs live

Useful searches:

grep CRON /var/log/syslog | tail -n 20
journalctl -u cron --since "1 hour ago"
journalctl -u crond --since today | grep backup

A typical line looks like this:

Oct 18 03:00:01 web1 CRON[48211]: (deploy) CMD (/opt/app/backup.sh >> /var/log/backup.log 2>&1)

If the line is there, cron did its part - the problem is inside the job. If it is missing, look at the schedule, the crontab owner and whether the daemon runs at all: systemctl status cron (or crond).

Capturing each job's output

Redirect both output streams for every job you care about:

0 3 * * * /opt/app/backup.sh >> /var/log/app/backup.log 2>&1

• >> appends instead of overwriting each run.
• 2>&1 sends errors to the same file - most failures are on stderr.

Add timestamps and exit codes

A log full of output with no dates is hard to read. A small wrapper fixes that:

#!/bin/bash
# /usr/local/bin/cronlog - run a command, prefix its output with timestamps
name="$1"; shift
{
  echo "=== $(date '+%F %T') start $name"
  "$@" 2>&1 | while IFS= read -r line; do echo "$(date '+%F %T') $line"; done
  code=${PIPESTATUS[0]}
  echo "=== $(date '+%F %T') end $name exit=$code"
} >> "/var/log/cron-jobs/$name.log"

0 3 * * * /usr/local/bin/cronlog backup /opt/app/backup.sh

Keep logs from filling the disk

Add a logrotate rule for your job logs:

/var/log/cron-jobs/*.log {
    weekly
    rotate 8
    compress
    missingok
    notifempty
}

Debugging a job that didn't run

Work through these in order:

1. Did cron start it? Search the daemon log for the command at the expected minute.
2. Is the schedule what you think? Check the five fields and the server's time zone with timedatectl.
3. Is it the right crontab? crontab -l for the user, /etc/cron.d/ and /etc/crontab for system jobs.
4. Does the command work in cron's environment? Run it with env -i, a minimal PATH and /bin/sh.
5. What did it print? Read the job's own log file.
6. Is it still running? pgrep -af backup.sh - a stuck previous run plus a lock file can block every new one.

Our guide to editing crontab safely covers the environment problems behind most of these failures.

From logs to alerts

Logs are great for the post-mortem and useless at 3 a.m. if nobody reads them. Two additions turn them into an early warning:

• Heartbeat monitoring - the job calls a URL on success; if the call is late, you get an alert. See cron job monitoring.
• Shipping logs centrally - sending job logs to a log platform lets you search across servers and alert on error patterns.

Frequently asked questions

• Why is there no cron log on my server?

  +

  Minimal installs and containers often run no syslog daemon, so cron has nowhere to write. Use journalctl if systemd is present, or redirect job output to files yourself.

• Can I make cron log more detail?

  +

  Some implementations accept a log-level flag (for example cron -L 15 on Debian's cron). Usually it's simpler to log inside the job itself.

• How do I see cron output without changing the job?

  +

  You can't recover output that wasn't captured. Set MAILTO to a working address or add redirection, then wait for the next run.