Creating Your First Cron Job: Step-by-step tutorial

If you need to run a script at a specific time without manual input, cron is the standard utility for the job on Unix-like systems. It allows you to schedule tasks – known as cron jobs – to run automatically in the background at fixed intervals, dates, or times.

Whether you are automating database backups, sending out weekly newsletters, or clearing out temporary cache files, the mechanism is the same. We are going to bypass the history lesson and jump straight into how you can set up the “cron table” (crontab) to automate your backend workflows.

Why would I create a cron job in the first place?

The primary benefit of a cron job is the “set and forget” reliability. By decoupling task execution from user interaction, you ensure that critical maintenance happens even when you aren’t logged in.

Manual execution is prone to human error; we forget to run the backup script, or we run the data sync twice by accident. Cron jobs provide consistency. They are essential for scheduling tasks and running healthchecks on your servers to ensure your infrastructure remains performant without you needing to wake up at 3 AM to push a button.

Understanding what a cron job is and how it works

At a high level, “cron” is a daemon (a background process) that runs continuously on your server. It wakes up every minute to check a configuration file called the crontab (Cron Table) to see if there are any jobs scheduled to run at that current minute.

If it finds a match, it executes the command. If not, it goes back to sleep until the next minute ticks over.

For a deeper dive into the daemon itself, check out our guide on Cron – what is it? which explains the system architecture in more detail.

Basics of cron job syntax for scheduling tasks

The syntax can look intimidating at first, but it follows a strict pattern. A standard cron entry consists of five asterisks followed by the command you want to run.

The structure looks like this:

* * * * * /path/to/command

Each asterisk (*) represents a unit of time:

1. Minute (0-59)
2. Hour (0-23)
3. Day of Month (1-31)
4. Month (1-12)
5. Day of Week (0-6, where 0 is Sunday)

If you want to master the wildcards, ranges, and step values (like */5 for “every 5 minutes”), read our specific breakdown of the Cron expression.

Step by step process for how to create a cron job using crontab

You don’t edit the cron configuration files directly. Instead, you use the crontab command-line utility. This handles the file permissions and syntax checking for you.

In this example, we will walk through the exact steps to schedule a script called backup.sh to run every night at 3:00 AM.

1. Edit the crontab file for your cron job

Step 1: Open the crontab editor Open your terminal and run the following command:

crontab -e

The -e flag stands for “edit.”

Note: If this is your first time running this command, the system will ask you to select an editor. Type 1 and press Enter to select Nano. It is the easiest editor for beginners.

Step 2: Insert the cron schedule. Once the file opens, you will likely see several lines of comments (lines starting with #) explaining how cron works.

1. Use your arrow keys to scroll all the way to the bottom of the file.
2. On a new blank line, type the following command exactly:

0 3 * * * /home/user/scripts/backup.sh

What did we just do?

• 0: The 0th minute.
• 3: The 3rd hour (3 AM).
• * * *: Every day, every month, every weekday.
• /home/user/scripts/backup.sh: The absolute path to the script you want to run.

Step 3: Save and Exit (If using Nano).
This is where many first-time users get stuck. To save the file in Nano:

1. Press Ctrl + O (this stands for “Write Out”).
2. Press Enter to confirm the filename.
3. Press Ctrl + X to exit the editor.

If you are successful, the terminal will print: crontab: installing new crontab. Your job is now active!

Common examples of cron job scheduling expressions

Now that you know how to enter them, here are a few other standard schedules you can copy and paste into your crontab.

Run a script every minute:

* * * * * /path/to/script.sh

Run a script every day at midnight:

0 0 * * * /path/to/script.sh

Run a script every Monday at 8:00 AM:

0 8 * * 1 /path/to/script.sh

If you need a specific schedule that isn’t listed here, you can generate one using an external tool like crontab.cronhub.io or view more examples in our Cron expression article.

Methods for verifying and testing your cron job

After you save and exit the editor, you want to make sure the job is actually registered. You can list all active cron jobs for your user by running:

crontab -l

The -l flag stands for “list.” If you see your 0 3 * * * command in the output, it is scheduled.

To verify it actually ran the next morning, you typically need to check the system logs. On Ubuntu/Debian systems, you can usually grep the syslog:

grep CRON /var/log/syslog

Alternative ways to create cron jobs

While the OS-level crontab is the standard, it isn’t the only way to schedule tasks. Many developers prefer to handle scheduling at the application level to keep the configuration within their codebase.

• Node.js: You can use packages like node-cron.
• Python: Libraries like APScheduler or Celery are popular.
• PHP: Many frameworks (like Laravel) have their own internal schedulers.

Common mistakes to avoid when creating cron jobs

I have seen many cron jobs fail silently because of one specific issue: Relative Paths.

When you run a script manually in your terminal, you are usually sitting in the project directory. Cron does not. Cron runs from the user’s home directory or the root directory.

Incorrect:

# This will likely fail because cron can't find script.py
0 * * * * python script.py

Correct:

# Always use full absolute paths
0 * * * * /usr/bin/python3 /home/ollie/project/script.py

Another common mistake is permissions. Ensure your script is executable (chmod +x script.sh) or that you are invoking the interpreter (like python or bash) explicitly in the cron line.

Tips and best practices for successful cron job creation

Monitoring and logging your cron job executions

By default, cron is silent. If your script crashes, cron won’t tell you; it just tries again next time.

To catch errors, you should redirect the output of your script to a log file. You can do this using standard Linux redirection operators:

* * * * * /path/to/script.sh >> /var/log/myscript.log 2>&1

The 2>&1 ensures that both standard output (success messages) and standard error (crash messages) are written to the log file.

For production systems, relying on local log files can be risky if the server disk fills up or you forget to check them. A more robust approach is to use an external monitor. Olic.io is a great tool for this.

Conclusion with final thoughts on how to create a cron job

Creating a cron job is a fundamental skill for backend development. It bridges the gap between manual scripting and scalable infrastructure. Once you understand the crontab -e workflow and the importance of absolute paths, you can automate virtually any part of your server stack.

Frequently Asked Questions about creating cron jobs

Do I need root access to create a cron job? No. Every user on a Linux system typically has their own crontab. However, if your script requires sudo privileges to run, you will need to edit the root user’s crontab using sudo crontab -e.

What happens if my computer is off when the cron job is scheduled? If the system is powered down, the cron job will simply be skipped. It does not “catch up” automatically when the computer turns back on.

How do I stop a cron job? Simply run crontab -e, delete the line containing the job, and save the file. The cron daemon will automatically pick up the change.