How to Set Up Cron Jobs on a Linux VPS: Complete Guide to Task Automation

Managing a server means dealing with the same tasks over and over: nightly database backups, cleaning up temp files, sending performance reports, updating records. Done manually, these tasks eat up time and invite human error. The solution has been built into Linux since the beginning — it's called cron, a background task scheduler available on every Linux distribution.

In this guide, you'll learn step by step how to configure cron jobs on a Linux VPS — from basic syntax to advanced examples, output logging, and troubleshooting.

---

What Is Cron and How Does It Work?

Cron is a daemon (background service) that runs continuously and checks whether any scheduled tasks need to be executed. Tasks are defined in special files called crontab (cron table).

Every Linux user can have their own crontab, and the system also maintains a global one at /etc/crontab. The cron daemon reads these files and runs the specified commands at the scheduled times.

Check if Cron Is Running

systemctl status cron        # Debian/Ubuntu
systemctl status crond       # CentOS/AlmaLinux/Rocky

If the service isn't active, enable and start it:

systemctl enable --now cron

---

Cron Job Syntax

Each line in a crontab follows this format:

* * * * * /path/to/command
│ │ │ │ │
│ │ │ │ └── Day of week (0-7, where 0 and 7 = Sunday)
│ │ │ └──── Month (1-12)
│ │ └────── Day of month (1-31)
│ └──────── Hour (0-23)
└────────── Minute (0-59)

Useful Operators

Operator	Meaning	Example
*	Any value	* * * * * = every minute
,	List of values	0 9,18 * * * = at 09:00 and 18:00
-	Range	0 9-17 * * * = every hour between 9 and 17
/	Step	*/15 * * * * = every 15 minutes

---

Editing the Crontab

To edit the current user's crontab:

crontab -e

To list existing jobs:

crontab -l

To edit another user's crontab (as root):

crontab -u www-data -e

Tip: On first run, you'll be asked to choose an editor. Pick nano if you're new to the terminal — it's friendlier than vim.

---

Practical Cron Job Examples

1. Daily MySQL Database Backup

0 2 * * * /usr/bin/mysqldump -u root -pYOUR_PASSWORD database_name > /backup/db_$(date +\%Y\%m\%d).sql

Runs every night at 02:00, saving a full database dump. On an NVMe VPS, fast I/O speeds keep backup windows short even for large databases.

2. Clean Up Old Temporary Files

0 3 * * 0 /usr/bin/find /tmp -type f -mtime +7 -delete

Runs every Sunday at 03:00 and deletes files in /tmp older than 7 days.

3. SSL Certificate Renewal

0 0 1 * * /usr/bin/certbot renew --quiet && systemctl reload nginx

Checks and renews SSL certificates on the first day of every month. Essential if you're using Let's Encrypt.

4. Daily Disk Usage Report via Email

0 8 * * * /usr/bin/df -h | /usr/bin/mail -s "Disk report $(hostname)" [email protected]

5. Running a PHP Script (e.g., WordPress)

*/5 * * * * /usr/bin/php /var/www/html/wp-cron.php > /dev/null 2>&1

WordPress has a built-in pseudo-cron that fires on page visits. For reliability — especially on a WordPress hosting plan with variable traffic — it's better to disable WP-Cron and use the system cron instead.

---

Environment Variables in Crontab

Cron runs with a minimal environment and does not inherit the user's shell variables. That's why you must always use absolute paths for commands.

You can define global variables at the top of your crontab:

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
[email protected]

• MAILTO — the email address to receive command output (set to "" to suppress emails entirely).
• PATH — the directories cron will search for executables.

---

Logging Cron Job Output

By default, cron sends command output via email (if sendmail is configured). A cleaner approach is redirecting output to log files:

0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

• >> appends output to the file (doesn't overwrite).
• 2>&1 redirects errors to the same file.

To prevent log files from growing indefinitely, pair cron with logrotate — another essential tool in the Linux server management toolkit.

---

System-Wide Cron: /etc/cron.d and the cron.* Directories

Beyond user crontabs, Linux provides predefined directories for system tasks:

Directory	Frequency
/etc/cron.hourly/	Hourly
/etc/cron.daily/	Daily
/etc/cron.weekly/	Weekly
/etc/cron.monthly/	Monthly

To add a script for daily execution, drop it into /etc/cron.daily/ and make it executable:

chmod +x /etc/cron.daily/myscript.sh

Files in /etc/cron.d/ support full crontab syntax including the username field:

0 4 * * * root /usr/local/bin/cleanup.sh

---

Securing Cron Jobs

A misconfigured cron job can become a security liability. Key best practices:

1. Don't run scripts as root unless absolutely necessary. Use least-privilege users.
2. Lock down script permissions. A chmod 777 script is a risk.
   bash chmod 700 /usr/local/bin/backup.sh chown root:root /usr/local/bin/backup.sh
3. Never store passwords in crontab. Use config files with restricted permissions (e.g., ~/.my.cnf for MySQL).
4. Control cron access via /etc/cron.allow and /etc/cron.deny.
5. Review cron logs regularly:
   bash grep CRON /var/log/syslog # Ubuntu/Debian grep CRON /var/log/cron # CentOS/AlmaLinux

On a managed dedicated server, our team handles these configurations for you.

---

Troubleshooting Cron Jobs That Don't Run

If a cron job fails silently, work through this checklist:

• Wrong path: Make sure every command uses its absolute path.
• Missing execute permission: The script must be executable (chmod +x script.sh).
• Missing environment variables: Add source ~/.bashrc at the top of your script, or define PATH in crontab.
• Syntax errors: Double-check with crontab -l and test the command manually in the terminal.
• Cron service not running: Check with systemctl status cron.

# Quick test: run the command as the cron user manually
su -s /bin/bash www-data -c "/usr/bin/php /var/www/html/script.php"

---

Alternative: systemd Timers

Modern Linux systems (Ubuntu 20.04+, AlmaLinux 8+) offer systemd timers as a more powerful alternative to cron. They support:

• Relative schedules (e.g., "5 minutes after boot").
• Integration with journald for centralised logging.
• Dependencies between services.

For most common use cases, however, cron remains simple, portable, and perfectly adequate. You can read more about advanced automation options on the CLIQHOST blog.

---

Conclusion

Cron jobs are a fundamental skill for any server administrator. With the right configuration, you can automate backups, maintenance, reporting, and much more — eliminating human error and saving hours of repetitive work.

For reliable execution of automated tasks, you need a stable and fast foundation. CLIQHOST NVMe VPS plans provide dedicated resources, high I/O throughput, and full root access — everything you need to run cron jobs confidently. Need help with server configuration? Explore our server management services or get in touch with our team — we're ready to help.