I see so many guides on how to run crontab, but what I need right now is to learn how to

  1. Find log files about cron jobs
  2. Configure what gets logged

Check if the programs you run with cron have their own log files. If if they don't but write their output to the standard outputs you can redirect these to files or mail them to you. Inside crontabs standard shell redirection works.

E.g. to redirect the error output of some_job.sh to some_job.err and discarding the standard output (i.e. sending it to /dev/null) add the following redirection to your crontab

 33 3 * * * /path/to/some_job.sh 1> /dev/null 2> /other/path/to/some_job.err

or to mail it to you instead (if mail is available)

 33 3 * * * /path/to/some_job.sh 1> /dev/null 2>&1 | mail -s "cron output" you@example.org
| improve this answer | |
  • This is how I've always solved my cron issues. – physicsmichael Mar 21 '10 at 4:47
  • Is that second example right? Wouldn't it redirect everything to /dev/null? – Timmmm Nov 25 '12 at 17:44
  • 8
    @Timmmm: I does work. It first redirects everything from some_job.sh's stdout to /dev/null and only after its stderr to stdout (which now contains nothing itself anymore). That way only its stderr ends up in stdout and is passed on to mail. – Benjamin Bannier Nov 25 '12 at 18:34

Most cron daemons on platforms I've worked with automatically email the stdout/stderr of user cron jobs to the user whose crontab the job came from. I forget what happens to system-wide (non-user-specific cron jobs from /etc/crontab). The thing is people don't always set up a mailer daemon (that is, a Mail Transfer Agent (MTA) like sendmail, qmail, or postfix) on most Unix-like OSes anymore. So the cron job output emails just die in a local mail spool folder somewhere if they even get that far. So one answer might just be to fire up your mailer daemon, and maybe make sure you have a ~/.forward file to forward your local mail along to your "real" email account.

If you want your jobs to write to specific log files, you can use standard output redirection like @honk suggested, or, supposing your cron job is a shell script, you could have your script call logger(1) or syslog(1) or whatever other command-line tool your OS provides for sending arbitrary messages to syslog. Then you could use your OS's built-in methods for configuring which kinds of messages get logged where, perhaps by editing /etc/syslog.conf.

Most of my cron jobs invoke bash scripts I wrote specifically for the purpose of being started by cron for a particular reason. In those, especially when I'm initially writing and debugging them, I like to use bash's "set -vx" to make the unexpanded and expanded form of each line of the shell script get written to stdout before it gets executed. Note that shell scripts started from cron are considered non-login, non-interactive shells, so your standard shell startup scripts like .bashrc and .profile aren't run. If you use bash and want bash to run a startup script, you have to define an environment variable "BASH_ENV=/path/to/my/startup/script" in your crontab before the line where you define the job.

| improve this answer | |
  • 3
    This is correct. One can use mail command to read messages from the command line. Or look at /var/spool/mail. But if you have installed postfix or other mailer than standard sendmail, another way to read messages is needed. – akostadinov Feb 19 '15 at 16:44
  • Why do we need a mail service agent just for this? mail -s "cron output" test@example.com works just fine :/ – Martin Konecny Mar 21 '17 at 19:54
  • On CentOS, my cron output gets "mailed" to /var/spool/mail. See it by running less $MAIL if you want to see cron output for the current user or less /var/spool/mail/root if you want to see cron output for commands running as root. – sffc Jul 7 '17 at 10:09

The tasks cron is executing are responsible for their own logging.

| improve this answer | |

I think redirecting within the cron-file might not be the best option in this case.

Often you want the logging speification co-located with the cron job script. In this case, I suggest the following:

exec &>> capture-log.txt
echo "Running cron-job foo at $(date)"
<rest of script>

This appends the output from the cron job to the capture-log.txt file.

| improve this answer | |
  • This is the right answer – Aerodynamika Jun 23 at 10:45

I prefer to get e-mail reports about cron jobs. Just put


into crontab and you will get an email. Of course you have to have e-mail configured for your account.

| improve this answer | |
  • I find this to often be the easiest to turn on and off for debugging. I typically just use username@localhost for the email address. – flickerfly Jul 18 '14 at 20:15

The most simple way is capture print errors and savem then in a file. I have a cronjob that call a php command line, like this:

1 0 * * * php /pathOfMyApp/index.php controllerName functionName > /pathOfMyApp/log/myErrorLog 2>&1

The part before '>' it's my cronjob and after '>' it's the capture and save in a file located in a log folder in the root of my project, but could be in the place you want. Be alert: everytime cronjob will be called he will overwrite the last log. You can use '>>' to write in the end of a existing file or search for 'cat' terminal command.

If your crontab uses 'curl' or 'wget' and refer to a link, you can search in /var/log/httpd/appName for access-log, if cron is returning with 500 or 400 must be something wrong.

At last, you can check /var/log/messages too.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.