Crontab Syntax Explained: Schedule Cron Jobs on a Linux VPS

Crontab syntax is the set of rules used to define when and how often cron jobs run on a Linux VPS. You write a line with five time fields (minute, hour, day of month, month, day of week) followed by the command to execute, and the cron daemon runs that command on the schedule you specify. This article breaks down each field, shows real examples, and covers the most common pitfalls so you can schedule tasks with confidence.

Formula

The number of times a cron job runs per day is simply the number of minutes in a day divided by the interval in minutes, multiplied by the number of commands scheduled at that interval:

Runs per day = (1440 / interval_minutes) × number_of_commands

• interval_minutes – the time between runs, in minutes (e.g., 5 for every 5 minutes).
• number_of_commands – how many separate cron entries use that same interval.

This is a planning aid: it tells you how many times a task will fire in a 24‑hour period, which helps estimate load or log volume.

Worked Example

Using the default values from the calculator – an interval of 5 minutes and 1 command:

1. Minutes in a day: 24 × 60 = 1440.
2. Divide by the interval: 1440 ÷ 5 = 288.
3. Multiply by the number of commands: 288 × 1 = 288.

The calculator shows 288 runs per day, which matches the formula. If you had two commands on the same 5‑minute schedule, it would be 576 runs per day.

What Is Crontab and Why Use It on a VPS?

On a Linux VPS, cron is a time‑based job scheduler that runs commands automatically at specified intervals. The crontab is the file that holds those schedules, one per user. You edit it with crontab -e and list it with crontab -l. Common uses include rotating logs, sending backup scripts, updating DNS records, cleaning temporary files, and sending scheduled emails. Because a VPS runs 24/7, cron is the standard way to automate maintenance without needing a human to trigger it.

The Five Time Fields

A cron line has six parts separated by spaces: five time fields and the command. The fields are:

1. Minute (0–59) – the exact minute the job runs.
2. Hour (0–23) – the hour, in 24‑hour format.
3. Day of month (1–31) – the day of the month.
4. Month (1–12 or jan–dec) – the month.
5. Day of week (0–7 or sun–sat) – 0 and 7 both mean Sunday.
6. Command – the shell command to execute.

Each time field accepts a number, a comma‑separated list (1,15), a range (9-17), a step (*/10), or a combination. The asterisk * means “every possible value.â€� For example, 0 3 * * * runs at 3:00 AM every day, while */15 * * * * runs every 15 minutes.

How to Choose the Right Schedule

Selecting the correct fields depends on what the job does and how often it needs to happen.

• Frequent tasks (every minute or every few minutes) – use * * * * * or */5 * * * * for every 5 minutes.
• Daily tasks – set a specific hour and minute, e.g., 0 2 * * * for 2:00 AM.
• Weekly tasks – use the day‑of‑week field, e.g., 0 3 * * 0 for 3:00 AM every Sunday.
• Monthly tasks – use the day‑of‑month field, e.g., 0 4 1 * * for 4:00 AM on the 1st.
• Multiple times per day – list hours or use a range, e.g., 0 9,12,15 * * * runs at 9 AM, noon, and 3 PM.

Be careful with the day‑of‑month and day‑of‑week fields: if both are restricted, cron runs the job when either condition matches (it’s an OR, not an AND). For example, 0 0 1 * 1 runs on the 1st of the month and on every Monday, not only when the 1st is a Monday.

Common Cron Mistakes and How to Avoid Them

Even experienced admins hit these traps:

• Forgetting the minute field – * * * * * runs every minute, not every hour. To run hourly, use 0 * * * *.
• Using 24‑hour vs 12‑hour time – cron uses 24‑hour time only. 0 3 * * * is 3 AM, not 3 PM.
• Day of week confusion – 0 and 7 are both Sunday. Some systems use 1=Monday, others 1=Sunday; always verify with man 5 crontab.
• Not using absolute paths – cron runs with a minimal PATH. Use /usr/bin/php instead of php, and always specify full paths to files.
• Ignoring output – if a command produces output, cron emails it to the user (if mail is set up). Redirect output to a log file: command >> /var/log/myjob.log 2>&1.
• Editing the wrong crontab – crontab -e edits the current user’s crontab. System‑wide jobs go in /etc/crontab or /etc/cron.d/, which have an extra user field.

Special Strings and Shortcuts

Cron supports a few named shortcuts that replace the five time fields:

• @reboot – runs once at startup.
• @daily – equivalent to 0 0 * * *.
• @hourly – equivalent to 0 * * * *.
• @weekly – equivalent to 0 0 * * 0.
• @monthly – equivalent to 0 0 1 * *.
• @yearly – equivalent to 0 0 1 1 *.

These are handy but not universally available on every cron implementation; they work on most modern Linux distributions.

Testing and Debugging Your Cron Jobs

Before relying on a cron job, test the command manually in the shell. Then add it to the crontab and check the logs. On most systems, cron logs to /var/log/syslog or /var/log/cron. You can also add a temporary line to write a timestamp to a file: * * * * * echo "ran at $(date)" >> /tmp/cron_test.log. If the job doesn’t run, check that the cron service is active (systemctl status cron or service cron status), that the script is executable, and that the shebang line (e.g., #!/bin/bash) is correct.

Security and Permissions

Only root and users listed in /etc/cron.allow can create crontabs. If cron.allow doesn’t exist, the system may use /etc/cron.deny to block specific users. Always run cron jobs with the least privilege needed. For example, if a backup script only needs to read certain files, don’t run it as root. Also be cautious with commands that write to system directories; a typo in a cron line can overwrite important files. Use absolute paths and quote arguments with spaces.

Alternatives to Cron

While cron is the classic scheduler, other tools exist for more complex needs:

• systemd timers – the modern replacement on many distributions, with more precise control and better logging.
• Anacron – runs missed jobs after a reboot or downtime, useful for laptops or VPS that may be suspended.
• At – schedules a one‑time job for a specific time.
• Web‑based schedulers – like Jenkins or GitLab CI, if you need complex workflows and a GUI.

For most simple recurring tasks on a VPS, cron remains the simplest and most reliable choice.

Frequently Asked Questions

How do I edit my crontab?

Run crontab -e to open your crontab in the default editor. If it’s your first time, you may be asked to choose an editor. After saving, cron automatically loads the new schedule. To see your current crontab, use crontab -l.

Why isn’t my cron job running?

Check the basics: is the cron service running? Did you use the correct syntax? Does the command work when run manually? Look for errors in the system log (grep CRON /var/log/syslog). Also verify that the script has execute permissions and that the shebang line points to the correct interpreter.

What does “*/5� mean?

The asterisk with a step value means “every N units.â€� */5 in the minute field means every 5 minutes (0, 5, 10, …). In the hour field, */2 would mean every 2 hours (0, 2, 4, …).

Can I run a cron job every second?

No, cron’s minimum granularity is one minute. To run a command every second, you’d need a loop inside a script or a different tool like systemd timers with OnUnitActiveSec=1s, but that’s not recommended for most tasks because it can overload the system.

How do I prevent cron from emailing me every time?

Redirect the command’s output to a file or to /dev/null. For example: 0 2 * * * /usr/bin/backup.sh > /dev/null 2>&1. This discards both stdout and stderr, so cron won’t send an email.

What is the difference between /etc/crontab and crontab -e?

crontab -e edits the user‑specific crontab, which doesn’t have a user field. /etc/crontab is the system‑wide crontab, where each line includes the user to run the job as (e.g., 0 2 * * * root /usr/bin/backup.sh). Use system crontab only for system‑wide tasks.

Related

• Recover Overwritten Files Windows 10: Full Guide
• Excel Split Comma Separated Values: 3 Quick Ways
• Google Find My Device: Track Friends?

in t | Time interval (minutes) | min | 5 | 1
in c | Number of commands | - | 1 | 1
out runs | Runs per day | - | (1440 / t) * c | 0