The Complete Guide to Cron Jobs
Max Rozen | Last updated: October 03, 2023
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
- Common cron job errors
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.
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.
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.
(*): The asterisk signifies "any" or "every." For example, an asterisk in the minute field would mean "every minute."
(,): You can use a comma to specify multiple values. For instance,
1,15in the minute field would mean "at 1 and 15 minutes past the hour."
(-): A hyphen defines a range. For example,
1-5in the hour field would indicate "every hour between 1am and 5am."
(/): A slash specifies increments. For example,
*/15in the minute field would indicate "every 15 minutes."
- Run a job every minute:
* * * * * /path/to/command
- Run a job every 15 minutes:
*/15 * * * * /path/to/command
- Run a job on the 15th minute of every hour:
15 * * * * /path/to/command
- Run a job every day at 3am:
0 3 * * * /path/to/command
- Run a job every Monday at 4:30pm (1630 in 24h time):
30 16 * * 1 /path/to/command
- Run a job every 15 minutes:
*/15 * * * * /path/to/command
- 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.
If you're like me and are still not used to using
vi for editing, you can change the editor
crontab uses like so:
EDITOR=nano crontab -e
While being a deceptively simple-looking table, there's a lot that can go wrong with setting up your cron jobs.
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.
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.
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.
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
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.
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.
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.
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.