The Complete Guide to Cron Jobs

If you don't know what a "cron job" is or how the cron job expression syntax works (and at this point are too afraid to ask), you're in the right place.

In this article, we'll dive into what is a cron job, how they work, and the details that often get overlooked, like cron job schedule syntax and common cron job errors.

Table of Contents

• Understanding cron jobs
• How cron jobs work
• Cron job schedule syntax
  • Special characters
  • Examples
  • Changing the editor crontab uses
• Common cron job errors
  • Incorrect syntax
  • Permissions issues
  • Ignoring output and error messages
  • Incorrect file paths
  • Not considering environment variables
  • Overlapping cron jobs
  • Forgetting time zones
• Conclusion

Understanding cron jobs

To understand cron jobs, we should probably talk about what cron is first.

cron is a time-based job scheduler in Unix-like operating systems. Users can schedule jobs (commands or scripts) to run at specific times or on specific days.

For example, you can schedule a job that backs up your database every night at midnight, or send out an email report to customers every Friday afternoon.

How cron jobs work

You write a small script that performs a specific action. This script is then executed by a cron daemon at specified intervals. The cron daemon is a background process that runs on the server and runs tasks at scheduled intervals. It scans for tasks to run every minute, runs them, and manages the output (it can send job output as an email to the user or save it to a specified log file).

The schedule for these jobs is stored in a special file known as the crontab (cron table). Each user can have their own crontab, and commands in the crontab are executed as the user who owns the crontab. The syntax of the crontab file specifies the minute, hour, day, month, and day of the week that a task should be executed.

Cron job schedule syntax

In a crontab file, each line represents a single cron job and follows a particular syntax. A cron expression typically consists of five fields, separated by spaces, followed by the command to be executed.

* * * * * [optionally, username to run as] command-to-be-executed
- - - - -
| | | | |
| | | | +---- Day of the week (0 - 7) [Both 0 and 7 represent Sunday]
| | | +------ Month (1 - 12)
| | +-------- Day of the month (1 - 31)
| +---------- Hour (0 - 23)
+------------ Minute (0 - 59)

Some tools such as node-cron use a sixth field to represent seconds.

Special characters

• Asterisk (*): The asterisk signifies "any" or "every." For example, an asterisk in the minute field would mean "every minute."
• Comma (,): You can use a comma to specify multiple values. For instance, 1,15 in the minute field would mean "at 1 and 15 minutes past the hour."
• Hyphen (-): A hyphen defines a range. For example, 1-5 in the hour field would indicate "every hour between 1am and 5am."
• Slash (/): A slash specifies increments. For example, */15 in the minute field would indicate "every 15 minutes."

Examples

1. Run a job every minute:

* * * * * /path/to/command

2. Run a job every 15 minutes:

*/15 * * * * /path/to/command

3. Run a job on the 15th minute of every hour:

15 * * * * /path/to/command

4. Run a job every day at 3am:

0 3 * * * /path/to/command

5. Run a job every Monday at 4:30pm (1630 in 24h time):

30 16 * * 1 /path/to/command

6. Run a job every 15 minutes:

*/15 * * * * /path/to/command

7. Run a job every day at 4pm and 5pm:

0 16,17 * * * /path/to/command

After updating your crontab, it's a good practice to confirm the jobs were saved correctly. You can do this by running crontab -l to list the cron jobs for the current user.

Changing the editor crontab uses

If you're like me and are still not used to using vim or vi for editing, you can change the editor crontab uses like so:

EDITOR=nano crontab -e

Common cron job errors

While being a deceptively simple-looking table, there's a lot that can go wrong with setting up your cron jobs.

Incorrect syntax

Probably the most common issue.

Folks often forget the specifics of cron job schedule syntax or make typos, causing cron to either not run the job or run it at the wrong times. Always double-check your syntax and test it out if possible.

You can use OnlineOrNot's free cron schedule expression helper to double check your syntax.

Permissions issues

Folks sometimes forget that a cron job will run (by default) as the user who created it and with that user's permissions.

You can run a cron job as a specific user, using the following syntax:

* * * * * username_to_run_as_here command_to_be_executed_here

If the user doesn't have permission to execute a script or command, the cron job will fail. Always ensure the user has the correct permissions for the script you want to run.

Ignoring output and error messages

By default, cron sends the output of the job and any error messages to the user's mail on the system. Ignoring these messages or not redirecting them to a log file can lead to missing crucial information about why a job failed.

Incorrect file paths

It's common to see cron jobs fail because of incorrect file paths. Always use absolute paths for commands and files to avoid any ambiguity.

For example, instead of ~/myscript.sh, use /home/username/myscript.sh.

Not considering environment variables

Cron jobs run in a limited environment, which means that they may not have access to all the same paths and variables as your user. This is often overlooked and can cause a cron job to fail because it can't find a particular command or doesn't have some other environment variable it needs.

In some Linux distributions, like Ubuntu and Debian, you can even define environment variables inside the crontab file, like so:

SOME_SECRET=this-is-secret

* * * * *   run_command_with_secret

It's worth noting that variables in your environment variables defined in your crontab won't be substituted (as in bash), so PATH=/usr/local/bin:$PATH would be interpreted as-is, while environment variables defined in the command will work as expected.

Overlapping cron jobs

Scheduling too many jobs, or jobs that take a long time to execute can lead to overlapping executions, which might lead to high CPU usage, data corruption, or other unexpected behaviors.

Always make sure to give your jobs enough time to complete before the next one starts.

Forgetting time zones

Folks often overlook the system’s time zone when configuring cron jobs.

If your tasks are time-sensitive or coordinated across different time zones, this could lead to unexpected behaviors. Always know what time zone your server is using.

You can run date +%Z to get the system's timezone.

Conclusion

So there you have it, everything you need to know about cron jobs.

From understanding what is a cron job to digging into how cron jobs work, cron job schedule syntax, and common cron job errors.