Operating systems for Unix and Linux have included the cron job scheduler for many years. It is widely used and frequently very trustworthy. Finding cron jobs on your server, verifying their schedules, and troubleshooting typical issues are all covered in this guide.

In this guide

  1. The common reasons cron jobs fail
  2. What to do if your cron job isn’t running when expected
  3. What to do if your cron job fails unexpectedly
  4. What to do if nothing else works

The common reasons cron jobs fail

Cron jobs can fail for an infinite number of reasons, but at Cronitor, we’ve noticed common failure patterns that can serve as a helpful place to begin your debugging process. In the remaining chapters of this guide, we’ll examine these common errors and provide guidance and solutions.

If a new cron job you add doesn’t run, you should…

  • **Schedule mistakes are simple to make
    **Expressions used in cron job schedules are peculiar and challenging to write. The simplest thing to rule out if your job didn’t run when you expected it to is a typo in the cron expression.
  • **Cron differs slightly from its environment.
    **It’s not uncommon to run into jobs that function perfectly when run from the command line but malfunction whenever run by cron. When this occurs, avoid these frequent mistakes:
    1. Try using an absolute path if the command’s path is unresolvable, like../scripts.
    2. (Cron does not load.bashrc and similar files) The job makes use of environment variables.
    3. While cron uses /bin/sh by default, the command makes use of advanced bash features.
  • Tip: CronitorCLI, our free program, has a shell command to test-run any job in the same manner as cron.
  • There is a permissions issue, and this guide will cover all three possible ways that improper permissions can make your cron jobs fail.

If an unexpected failure of your cron job occurred…

  • **The system’s resources have run out.
    **Even the most reliable cron job cannot compete with a full disk or an OS that cannot create new threads. To rule this out, look through all the typical graphs.
  • **You’ve come to a turning point.
    **The limitations of your stack can be revealed by using cron jobs for batch processing and other data-intensive tasks. Jobs frequently proceed without issues until the data size causes queries to time out or file transfers to become unacceptably slow.
  • **There is infrastructure drift
    **It is simple to forget about the cron jobs running on each server when app configuration and code modifications are deployed. As a result, hosts retire or credentials change, breaking the abandoned cron jobs, and causing infrastructure drift.
  • The beginning of job overlap Cron is a very basic scheduler that starts a job at the scheduled time, even if the previous invocation is still running. A slight slowdown can cause a backlog of jobs that overlap one another, sapping resources.
  • **There has been an error.
    **A failure may occasionally be unrelated to cron. Cron jobs can be challenging to thoroughly test in a development environment, and a bug might only exist there.

How to proceed if your cron job doesn’t execute when it should

It’s possible that a cron job you scheduled is simply not running when it should. To find your scheduled job and identify the issue, follow these steps.

  1. Find the scheduled task.
    ** **Advice: If you already know where your job is scheduled, skip this step.     _
    _A system daemon called crond manages cron jobs and keeps an eye out for scheduled tasks in various places. Find out where your job is scheduled in order to begin comprehending why it didn’t start when anticipated.
    Lookup cron jobs manually on your server.

Use crontab -l dev01 to check your user crontab: $ crontab -l

  • 5 4 * * * /var/cronitor/bin/database-backup.sh
  • Jobs are commonly created by adding a crontab file in /etc/cron.d/
  • System-level cron jobs can also be added as a line in /etc/crontab
  • Sometimes for easy scheduling, jobs are added to /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/ or /etc/cron.monthly/
  • Check each user’s crontab by using the command crontab -u username -l to see if the job was created in their crontab.
  1. You could also use CronitorCLI to automatically search for cron jobs.
    • Freely download CronitorCLI
    • To search for cron jobs on your system, run cronitor list
  2. Double-check that you are on the right server if you can’t find your job but think it was previously scheduled.
  3. **Verify your work schedule.
    **As soon as you locate your position, make sure the schedule is accurate. Cron schedules are frequently used because they are expressive and powerful, but they can occasionally be challenging to read, like regular expressions. To verify your schedule, we advise using Crontab Guru.
    • Copy the schedule expression from your crontab and paste it into the Crontab Guru text box.
    • Make sure your schedule is translated correctly into plaintext and that the next scheduled execution times correspond to your expectations.
    • Verify that your expectations match the actual server timezone. In addition to using date to check the system time, look in your crontab file for any TZ or CRON_TZ timezone declarations that might override system preferences. For example, CRON_TZ=America/New_York
  4. **Verify your authorizations
    **Your cron jobs could fail in one of at least three ways due to invalid permissions:
    • A /etc/cron.*/ directory’s files containing new jobs must be owned by root. Other users’ files will be ignored, and your syslog may contain a message that reads WRONG FILE OWNER.
    • The user that cron is running your job as must be capable of executing the command. Ubuntu must have permission to execute the script, for instance, if your user’s crontab calls a script like database-backup.sh. The simplest method is to make sure the database-backup.sh file is owned by the Ubuntu user and then check that execute permissions are available using chmod +x.
    • Cron usage must be permitted for the user account. The user needs to be listed in any /etc/cron.allow files that already exist. The user cannot be included in a /etc/cron.deny list independently.
  5. Make sure to escape the character a% in your command string with a backslash if it appears. This is related to the permissions issue.
  6. **Look for the attempted execution of your cron job in Syslog to confirm that it is running.
    **Whenever cron tries to execute a command, it logs the attempt in Syslog. You can confirm that cron is running and that your job is scheduled properly by grepping Syslog for the name of the command you discovered in a crontab file.

Start by grepping through /var/log/Syslog for the command. Most likely, you’ll require root or sudo access.)

dev01: ~ $ grep database-backup.sh /var/log/syslog

  • Aug 5 4:05:01 dev01 CRON[2128]: (ubuntu) CMD (/var/cronitor/bin/database-backup.sh)
  • It’s possible that the Syslog has been rotated or cleared since your job ran if you can’t find your command there. If at all possible, rule that out by changing the job’s schedule to * * * * * and updating it to run every minute.

The underlying cron daemon known as crond may be malfunctioning if your command doesn’t show up as an entry in syslog within 2 minutes. Quickly rule this out by confirming that cron is active by locating its process ID. No process ID will be returned if the cron is not active.

dev01: ~ $ pgrep cron

  • Double-check that crond has properly loaded your crontab file if you’ve located your job in a crontab file but are still unable to find it referenced in Syslog. Running EDITOR=true crontab -e from your command prompt will force a reparse of your crontab, which is the simplest way to accomplish this. If everything is current, a message such as “No modification made” will appear. Any other message means that your crontab file has been updated and was not previously loaded after an update. This will also guarantee that there are no syntax errors in your crontab file.

You can assume there is a problem with the command you are attempting to run if you can see in the syslog that your job was scheduled, attempted to run correctly, but still did not yield the desired result.

Where on your server do cron logs reside

The cron daemon runs tasks on a schedule by reading crontab files, and the logs it produces are useful for debugging and auditing your cron jobs. Most versions of cron will log whThe majority of cron software will track when jobs are executed and whether your crontab contains any errors. exit statuses. (For that, use Cronitor.)

  1. Cron log retrieval on Ubuntu and Debian Cron job logs can be found in /var/log/Syslog on Debian, Ubuntu, and other comparable distributions. Grep can be used to identify messages specific to cron because your Syslog contains entries from numerous operating system components.
    grep CRON /var/log/syslog
    You will likely require root/sudo privileges to access your Syslog.
  2. **Cron log retrieval on CentOS and Redhat
    **cron logs are written to /var/log/cron on CentOS, Redhat, and Amazon Linux systems. tail /var/log/cron
    In order to access your cron logs, you probably need root or sudo privileges.
  3. **Making sense of your cron job logs
    **In cron logs, the time the job was started, the user account used, and the command executed are all recorded. In this illustration, a data-pipeline.py cron job was run on the data-processing host on March 29 under the data proc user.

Cron logs are useful, but they can’t tell you which cron jobs weren’t executed. Although logs are helpful, they are unable to reveal which cron jobs were skipped. Cronitor can be used to easily collect output from your cron jobs, record errors, and notify you when something goes wrong.