What Is a Cron Job and Why Every Server Relies on It

A cron job is a scheduled task that runs automatically at a defined time or interval on Unix-based operating systems. The name comes from “chronos,” the Greek word for time. Every Linux server, macOS machine, and most web hosting environments use the cron daemon to execute scripts, commands, or programs without any manual trigger.

How the Cron Daemon Works

The cron daemon (crond) starts at boot and stays running in the background. It checks a set of configuration files called crontabs once per minute, comparing each entry’s schedule against the current system time. When a match occurs, the daemon spawns a shell process and executes the associated command.

Each user on the system can have their own crontab, and there is also a system-wide crontab located at /etc/crontab. Root-level cron jobs typically handle log rotation, package updates, and certificate renewals. User-level cron jobs cover anything from sending report emails to clearing temporary files.

Crontab Syntax Broken Down

The schedule portion of every cron job entry follows a five-field pattern. Each field represents a time unit, and the order never changes.

* * * * * /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)

An asterisk () means “every possible value.” A forward slash indicates step values, so /5 in the minute field means “every 5 minutes.” Commas separate multiple specific values (1,15,30), and hyphens define ranges (9-17 for business hours). These four operators cover virtually every scheduling pattern a server administrator needs.

Practical Examples You Can Use Today

Running a database backup every night at 2:00 AM looks like this:

0 2 * * * /usr/bin/mysqldump -u root -pYOURPASS mydb > /backups/mydb_$(date +%F).sql

Clearing PHP session files older than 24 hours every 6 hours:

0 */6 * * * find /var/lib/php/sessions -type f -mmin +1440 -delete

Those two examples alone eliminate hours of manual maintenance per month. The key is keeping each command idempotent, meaning running it twice produces the same result as running it once, so overlapping executions never corrupt data.

Managing Cron Jobs Through the Terminal

Editing your crontab is straightforward.

crontab -e   # Open your crontab in the default editor
crontab -l   # List all your current cron jobs
crontab -r   # Remove your entire crontab (use with caution)

System administrators who need to manage cron jobs for other users append -u username to any of these commands. On servers where multiple developers deploy code, restricting crontab access through /etc/cron.allow and /etc/cron.deny prevents accidental overwrites. Working with WP-CLI over SSH gives you the same terminal access pattern for WordPress-specific tasks.

Where Cron Jobs Fail (and How to Catch It)

Cron runs silently by default. If a job fails, the only evidence is an email sent to the local user’s mailbox, which most people never check. This is the single biggest reason cron jobs “stop working” on production servers.

Redirecting output to a log file solves this immediately:

0 3 * * * /home/user/cleanup.sh >> /var/log/cleanup.log 2>&1

The 2>&1 sends both standard output and error output to the same file. Without it, errors vanish. Another common failure: environment variables. Cron does not load your .bashrc or .bash_profile, so paths like $HOME or custom $PATH entries are unavailable unless you define them at the top of your crontab or inside the script itself. A script that works perfectly when you run it manually in the terminal but breaks under cron almost always has an environment variable issue.

Cron in the Context of WordPress

WordPress has its own scheduling system called WP-Cron. It does not use the server’s cron daemon at all. Instead, WP-Cron triggers on every page load, checking if any scheduled event is overdue and executing it if so. This design means a site with zero traffic has zero scheduled task execution.

On high-traffic sites, the opposite problem appears: every single visitor triggers the WP-Cron check, adding unnecessary overhead to each request. Replacing WP-Cron with a real system cron job eliminates that per-request penalty and guarantees tasks run exactly when scheduled. The typical approach disables WP-Cron in wp-config.php and adds a crontab entry:

// In wp-config.php
define('DISABLE_WP_CRON', true);

*/5 * * * * curl -s https://yoursite.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

This fires WP-Cron every 5 minutes via an HTTP request instead of relying on visitor traffic. The result is consistent execution timing and reduced TTFB on every front-end request.

Cron Alternatives and Extensions

systemd timers have replaced cron on many modern Linux distributions. They offer dependency management, better logging through journalctl, and calendar-based scheduling syntax that some administrators find more readable. The trade-off is complexity: a systemd timer requires both a .timer unit file and a .service unit file, while cron needs a single line.

anacron fills a different gap. Standard cron skips a job entirely if the server was powered off during the scheduled time. anacron tracks whether a job has run within its defined period and executes it at the next opportunity, making it ideal for laptops and development machines that are not always on.

For WordPress environments running on shared hosting, cron access depends on the hosting plan. Some providers expose crontab through cPanel, while others restrict it entirely. Choosing a VPS over shared hosting gives full crontab control along with SSH access.

Security Considerations for Cron Jobs

Every cron job runs with the permissions of the user who owns the crontab entry.

A cron job owned by root that executes a world-writable script is an open backdoor. Any user on the system could modify that script and have their code executed as root on the next cron cycle. The fix: set strict file permissions (chmod 700) on every script referenced in a crontab, and never store credentials in the crontab itself. Use environment files with restricted read permissions or a secrets manager instead. Pairing cron job security with SSH-based access controls adds another layer of protection for web servers.

Audit your crontabs regularly with crontab -l for each user, and check /etc/cron.d/, /etc/cron.daily/, /etc/cron.hourly/, and /etc/cron.weekly/ for system-level entries that plugins or packages may have installed without your knowledge.

Automating Database Maintenance With Cron

Database tables fragment over time, especially on sites with frequent inserts and deletes. Running OPTIMIZE TABLE on a schedule prevents query performance from degrading month over month. A weekly optimization cron job for a WooCommerce store’s order tables can reduce query latency caused by table bloat by 15-30%, depending on order volume.

0 4 * * 0 /usr/bin/mysql -u root -pYOURPASS -e "OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options, wp_wc_orders;" mydb

That single line runs every Sunday at 4:00 AM. Combined with proper indexing, it keeps response times stable even as the database grows past hundreds of thousands of rows.

Monitoring Long-Running Cron Jobs

Some tasks take longer than the interval between executions. A backup script scheduled every hour that takes 90 minutes to complete will overlap with itself, potentially corrupting the backup or doubling server load. The standard solution is a lock file.

#!/bin/bash
LOCKFILE=/tmp/backup.lock
if [ -f "$LOCKFILE" ]; then
  echo "Previous run still active. Exiting."
  exit 1
fi
trap "rm -f $LOCKFILE" EXIT
touch "$LOCKFILE"
# ... actual backup commands here

The trap command ensures the lock file is removed even if the script crashes. Without it, a failed run would permanently block all future executions until someone manually deletes the lock file. Monitoring tools like Cronitor or Healthchecks.io ping a URL at the start and end of each job, alerting you if a job runs too long or fails to start.

Cron is one of those Unix tools that has survived decades because it does exactly one thing and does it reliably. Understanding its syntax, failure modes, and relationship to server performance separates administrators who react to problems from those who prevent them entirely.

Често задавани въпроси