What is a cron job? The complete cron guide

A cron job is a command or script that runs automatically on a schedule. Cron jobs are commonly used on Linux and other Unix-like systems for recurring work such as backups, reports, data imports, cache cleanup, and health checks.

For example, this crontab entry runs a backup script every day at 02:00:

0 2 * * * /home/user/backup.sh

The five values at the start describe the schedule. The rest of the line is the command cron runs.

Use the cron expression generator if you already know the schedule you need. Keep reading if you want to understand how cron works and set up a reliable cron job from start to finish.

How cron jobs work

Cron is a time-based scheduler. A background process called the cron daemon reads schedule files, checks them once per minute, and starts commands whose schedules match the current time.

The schedule file is called a crontab, short for "cron table." On most Linux systems, each user can have a separate crontab. Commands in that crontab run with that user's permissions and environment.

A cron job has two parts:

1. A schedule, written as a cron expression
2. A command, script, or program to execute

This entry runs /home/user/report.sh at 09:00 every Monday:

0 9 * * 1 /home/user/report.sh

Cron starts the command when the schedule matches. It does not automatically confirm that the command completed successfully, retry a failed command, or alert you when a run is missed.

Cron vs crontab vs cron job

These terms are related, but they do not mean exactly the same thing:

• cron is the scheduler and background service.
• crontab is the table containing cron schedules and commands. crontab is also the command used to edit that table.
• cron job is one scheduled command in a crontab.
• cron expression is the schedule portion of a cron job, such as */5 * * * *.

Cron expression syntax

A standard Unix cron expression contains five fields separated by spaces:

┌───────────── minute (0-59)
│ ┌───────────── hour (0-23)
│ │ ┌───────────── day of the month (1-31)
│ │ │ ┌───────────── month (1-12)
│ │ │ │ ┌───────────── day of the week (0-7)
│ │ │ │ │
* * * * *

Both 0 and 7 commonly represent Sunday. Some implementations also accept three-letter names such as MON and JAN.

The expression is followed by the command:

* * * * * command-to-run

A system-wide crontab, such as /etc/crontab, normally includes an additional username between the schedule and command:

* * * * * username command-to-run

Do not add that username field when editing your personal crontab with crontab -e.

Cron special characters

Cron expressions use a small set of operators:

Character	Meaning	Example
*	Every allowed value	* * * * * runs every minute
,	A list of values	0 9,17 * * * runs at 09:00 and 17:00
-	A range	0 9 * * 1-5 runs at 09:00 Monday through Friday
/	A step or interval	*/15 * * * * runs every 15 minutes

A step applies within its field. */5 in the minute field means every fifth minute, while 0 */5 * * * means every five hours on the hour.

Common cron job examples

Schedule	Cron expression
Every minute	* * * * *
Every 5 minutes	*/5 * * * *
Every 10 minutes	*/10 * * * *
Every 15 minutes	*/15 * * * *
Every 30 minutes	*/30 * * * *
Every hour	0 * * * *
Every day at midnight	0 0 * * *
Every day at 09:00	0 9 * * *
Every weekday at 09:00	0 9 * * 1-5
Every Sunday	0 0 * * 0
First day of every month	0 0 1 * *
Every year	0 0 1 1 *

Browse the complete list of cron expression examples for more schedules.

How to create a cron job on Linux

1. Check that cron is running

The service name varies by distribution. On Ubuntu and Debian, check cron:

systemctl status cron

On distributions that call the service crond, use:

systemctl status crond

2. Test the command manually

Run the exact command before scheduling it. Use absolute paths and make sure the current user has permission to execute the script:

/home/user/backup.sh

A script should include a valid shebang, such as #!/usr/bin/env bash, and be executable:

chmod +x /home/user/backup.sh

3. Open your crontab

Run:

crontab -e

Your system may ask you to choose an editor the first time. To explicitly use Nano for one edit, run EDITOR=nano crontab -e.

4. Add the schedule and command

Add one cron job per line. This example runs the backup at 02:00 every day and appends standard output and errors to a log file:

0 2 * * * /home/user/backup.sh >> /home/user/backup.log 2>&1

Save and close the file. Most cron implementations install the updated crontab automatically.

5. Confirm the cron job was saved

List the current user's cron jobs:

crontab -l

To inspect another user's crontab as an administrator:

sudo crontab -u username -l

How to test a cron job

Do not wait a week to discover that a weekly job is broken. Test it in layers:

1. Run the command manually as the same user that will run the cron job.
2. Temporarily schedule it for the next few minutes.
3. Redirect output to a known log file.
4. Confirm the expected result, not just that a process started.
5. Restore the intended schedule after the test.

The cron expression generator validates standard five-field expressions and previews the next run times. This catches syntax and timing mistakes before you edit the crontab.

Why cron jobs fail

Cron uses a limited environment

A command that works in your terminal can fail under cron because cron does not load the same shell configuration. Its PATH, working directory, environment variables, and shell may all differ.

Use absolute paths for scripts, executables, and files:

0 2 * * * /usr/bin/python3 /home/user/jobs/backup.py

Set required environment variables explicitly, but avoid putting secrets directly in a widely readable crontab.

Relative paths point somewhere unexpected

Cron does not necessarily run from your home directory or project directory. Change directories explicitly when a command depends on its working directory:

0 2 * * * cd /home/user/app && /usr/bin/npm run backup

The script lacks permissions

The user who owns the crontab must be able to read and execute the script and access every required file. Check ownership, executable permissions, and parent-directory permissions.

The server uses a different time zone

Cron normally interprets schedules in the server's local time zone. Check it with:

timedatectl

Daylight-saving changes can cause a local-time job to run twice or not at all. Use UTC when consistency matters, and document the time-zone assumption beside the schedule.

Runs overlap

If a job takes longer than its interval, several copies can run at once. On Linux, flock can prevent overlaps:

*/5 * * * * /usr/bin/flock -n /tmp/import.lock /home/user/import.sh

Decide what should happen when the lock is already held: skip the new run, queue it, or alert someone.

Failures are hidden

Redirecting output to /dev/null makes a crontab quiet, not reliable. Keep useful logs and configure an alert for failures or missed runs.

Cron implementation differences

The five-field format in this guide covers traditional Unix cron. Other schedulers use similar-looking expressions with different rules:

• Some libraries add a seconds field.
• Quartz commonly uses six or seven fields and characters such as ?, L, and #.
• AWS EventBridge uses six fields, requires ? in one day field, and interprets schedules in UTC by default.
• GitHub Actions scheduled workflows use POSIX cron syntax and UTC.
• Kubernetes CronJobs add cluster-specific concurrency, deadline, and time-zone behavior around a cron schedule.

Always check the documentation for the scheduler that will evaluate the expression. A valid expression for one implementation may be invalid—or mean something different—in another.

How to monitor a cron job

Cron starts commands, but it does not guarantee that they finish or notify you when a run never starts. Heartbeat monitoring fills that gap.

A heartbeat monitor gives your job a unique URL to ping after successful completion:

0 2 * * * /home/user/backup.sh && /usr/bin/curl -fsS --retry 3 https://oonchk.com/your-id

The && matters: the ping is sent only when the backup exits successfully. If the command fails or the job never starts, the expected ping is missing and the monitor alerts you.

For important jobs, monitor missed runs and command failures, retain logs, prevent overlaps, and allow a realistic grace period for normal variation. See the cron job monitoring guide or create a free heartbeat monitor.

Cron job FAQ

What is a cron job used for?

Cron jobs automate recurring commands. Common uses include backups, reports, database maintenance, data imports, cache cleanup, certificate renewal, and periodic health checks.

How do I run a cron job?

Test the command, run crontab -e, add a line containing the five-field schedule followed by the command, save the file, and verify it with crontab -l.

Where are cron jobs stored?

Personal cron jobs are managed with the crontab command. Their underlying storage location varies by operating system and should not normally be edited directly. System-wide schedules may also appear in /etc/crontab, /etc/cron.d/, or periodic directories under /etc.

Does cron run every second?

Traditional cron checks schedules once per minute and uses five fields. Some libraries support a sixth seconds field, but that is not portable Unix crontab syntax.

Does cron retry failed jobs?

Traditional cron does not automatically retry a command just because it exits with an error. Add retry behavior to the command or script when the operation is safe to repeat, and monitor the final result.

How can I tell whether a cron job ran?

Check the job's output, application logs, and your system's cron logs. For reliable detection of missed runs, add heartbeat monitoring rather than relying only on logs produced when a command starts.