Find cron logs on Ubuntu, Debian and RHEL-family Linux

Common locations are /var/log/syslog on Debian/Ubuntu and /var/log/cron on RHEL-family systems. They are conventions determined by the installed logging configuration, not guaranteed paths on every host. Minimal containers may have neither.

Start with the host's actual logging service, then distinguish cron daemon events from the output of the script it launches.

Inspect Debian and Ubuntu logs

On a host writing /var/log/syslog:

grep CRON /var/log/syslog
grep 'myjob.sh' /var/log/syslog

For live output on a system with GNU grep:

tail -F /var/log/syslog | grep --line-buffered CRON

-F follows the filename across rotation, while line buffering reduces delays in the filter. Read privileges may be needed. Searching for the script name only works when that name appears in the recorded command or application log.

Inspect RHEL-family logs or the journal

Where /var/log/cron is configured:

tail -n 100 /var/log/cron
tail -F /var/log/cron

On a systemd host, inspect the appropriate daemon unit:

journalctl -u cron --since today
journalctl -u crond --since today

Use the unit that exists on your distribution. Journal retention, permissions and forwarding affect what is available. An absent file does not establish that cron never ran.

Create a dedicated cron event file

If rsyslog is installed, inspect its existing configuration first. A rule in the appropriate configuration file can route cron-facility events to a separate path:

cron.*    /var/log/cron.log

Validate and apply the configuration:

sudo rsyslogd -N1
sudo systemctl restart rsyslog

Existing rules may still write those same events to the general syslog file. Decide whether that duplication is wanted. Configure retention and rotation for the new destination.

Capture the script's output and result

An entry such as (appuser) CMD (...) indicates a launch under that account. By itself, it says nothing about whether the application completed successfully.

0 2 * * * /home/appuser/job.sh >> /var/log/jobs/myjob.log 2>&1

Provision the destination for the job account. Have the script or a wrapper record its start, completion and exit status, ideally with a run identifier. Standard error is not inherently failure, and a silent command can still exit nonzero.

The usual default scheduler logs focus on starts, but logging capabilities vary. For example, Debian cron has configurable levels for job ends and failed exit statuses. Do not assume that no implementation can log results, or that its default configuration already does so.

Guance log collection can collect scheduler and application logs separately. Correlate host, job and run time, and verify collection with known events before diagnosing missing records.

Common questions

What does (root) CMD (...) mean? Cron recorded a command launch for root. It is not a success receipt.

Can journalctl show the task's stdout automatically? Do not assume so for traditional cron. Its mail/output handling differs from a systemd service. Configure an explicit output destination.

How do I establish success? Check the recorded exit code and the expected business result, such as an artifact or completed transaction. A launch line alone is insufficient.

References

• Debian cron logging levels
• rsyslog selector syntax
• GNU grep output buffering