What Is a Cron Job? A Guide for Website Owners

A cron job is a scheduled task that runs automatically at a set time or interval on a Unix-based server. It is the standard way to automate recurring work on Linux and macOS systems: generating reports, cleaning up old files, sending emails, pulling data from APIs, running backups, or any other task that needs to happen on a schedule without someone manually triggering it.

For website owners, cron jobs handle the behind-the-scenes maintenance that keeps a site running smoothly. Database cleanup, cache invalidation, sitemap generation, SSL certificate renewal, and backup creation are all common cron job use cases. For a broader view of what website maintenance involves, see the website maintenance and monitoring guide.

How Cron Works

Cron is a daemon (a background process) that runs on Unix-like operating systems. It wakes up every minute, checks a schedule file called the crontab (cron table), and runs any jobs whose scheduled time matches the current minute.

Each user on a system can have their own crontab. There is also a system-wide crontab at /etc/crontab and a directory of scripts at /etc/cron.d/. The user-level crontab is what you interact with most of the time.

When a cron job runs, it executes as the user who owns the crontab. It does not run in an interactive terminal session, which means it does not have the same environment variables, PATH, or working directory that you have when you SSH into the server. This is the source of most cron job problems: a command that works when you type it manually but fails when cron runs it because the environment is different.

Cron Syntax

Every line in a crontab follows a five-field schedule format, followed by the command to run.

* * * * * command-to-run
| | | | |
| | | | +--- Day of week (0-7, where 0 and 7 are Sunday)
| | | +----- Month (1-12)
| | +------- Day of month (1-31)
| +--------- Hour (0-23)
+----------- Minute (0-59)

Each field can be a specific value, a range, a list, or a step value:

• 5 means "at exactly 5"
• * means "every possible value"
• 1-5 means "1 through 5"
• 1,15 means "at 1 and at 15"
• */10 means "every 10 units"

Common Schedule Patterns

Here are the patterns that cover most use cases:

# Every minute
* * * * * /path/to/command

# Every 5 minutes
*/5 * * * * /path/to/command

# Every hour, at minute 0
0 * * * * /path/to/command

# Every day at midnight
0 0 * * * /path/to/command

# Every day at 3:30 AM
30 3 * * * /path/to/command

# Every Monday at 9:00 AM
0 9 * * 1 /path/to/command

# Every weekday at 6:00 AM
0 6 * * 1-5 /path/to/command

# First day of every month at midnight
0 0 1 * * /path/to/command

# Every 15 minutes during business hours (9 AM to 5 PM, weekdays)
*/15 9-17 * * 1-5 /path/to/command

# Every Sunday at 2:00 AM
0 2 * * 0 /path/to/command

Some cron implementations also support shorthand strings:

@reboot     # Run once at startup
@hourly     # Same as 0 * * * *
@daily      # Same as 0 0 * * *
@weekly     # Same as 0 0 * * 0
@monthly    # Same as 0 0 1 * *
@yearly     # Same as 0 0 1 1 *

These shorthands are easier to read but are not supported by every cron implementation. When in doubt, use the five-field format.

Crontab Commands

Managing your crontab is done through the crontab command.

# View your current crontab
crontab -l

# Edit your crontab (opens in your default editor)
crontab -e

# Remove your entire crontab (be careful)
crontab -r

# View another user's crontab (requires root)
crontab -u username -l

When you run crontab -e, the system opens the crontab file in your default editor (usually vi or nano). Add or modify lines, save the file, and cron picks up the changes immediately. No restart required.

A good practice is to always list your crontab (crontab -l) before editing to make sure you know what is already there. And always back up your crontab before making changes:

crontab -l > crontab-backup-$(date +%Y%m%d).txt

Website Use Cases for Cron Jobs

Cron jobs are the backbone of website automation. Here are the most common use cases.

Database Maintenance

Databases accumulate temporary data, expired sessions, old log entries, and orphaned records over time. A cron job can clean these up regularly:

# Clean expired sessions every hour
0 * * * * /usr/bin/php /var/www/site/artisan session:gc

# Optimize database tables weekly
0 3 * * 0 /usr/bin/mysqlcheck --optimize --all-databases -u admin -p'password'

Without regular cleanup, database performance degrades as tables grow with unnecessary data.

Backups

Automated backups are one of the most important cron jobs for any website. See the website backup strategy guide for a full approach.

# Daily database backup at 2 AM
0 2 * * * /usr/bin/mysqldump -u admin -p'password' mydb | gzip > /backups/db-$(date +\%Y\%m\%d).sql.gz

# Weekly full site backup on Sundays at 3 AM
0 3 * * 0 tar -czf /backups/site-$(date +\%Y\%m\%d).tar.gz /var/www/site/

Note the escaped % characters in the date format. In crontab, % is a special character (it represents a newline). Use \% to include literal percent signs.

SSL Certificate Renewal

If you use Let's Encrypt (certbot), your SSL certificates expire every 90 days. A cron job handles automatic renewal:

# Check and renew certificates twice daily (certbot's recommendation)
0 0,12 * * * /usr/bin/certbot renew --quiet

Certbot only renews certificates that are within 30 days of expiration, so running it twice daily is safe. It does nothing if the certificate is not due for renewal.

Cache Management

If your site uses file-based caching, old cache files can accumulate:

# Clear expired cache files every 6 hours
0 */6 * * * find /var/www/site/cache -type f -mtime +1 -delete

# Warm the cache after clearing (rebuild the most important pages)
5 */6 * * * /usr/bin/curl -s https://example.com/sitemap.xml | grep -oP '<loc>\K[^<]+' | head -20 | xargs -I {} curl -s {} > /dev/null

Sitemap Generation

If your site content changes frequently, regenerating the XML sitemap on a schedule ensures search engines always have current data:

# Regenerate sitemap daily at 4 AM
0 4 * * * /usr/bin/php /var/www/site/artisan sitemap:generate

Monitoring and Health Checks

Cron jobs can perform basic self-monitoring for your site. For a complete approach, see the website maintenance plan guide.

# Check if the site is responding every 5 minutes
*/5 * * * * /usr/bin/curl -sf https://example.com > /dev/null || echo "Site down at $(date)" >> /var/log/site-health.log

# Check disk space daily and alert if above 80%
0 8 * * * df -h / | awk 'NR==2 && int($5) > 80 {print "Disk usage: " $5}' | mail -s "Disk Alert" [email protected]

Email Sending

Queued emails (password resets, notifications, newsletters) are often sent by a cron job:

# Process email queue every minute
* * * * * /usr/bin/php /var/www/site/artisan queue:work --stop-when-empty

Common Cron Job Mistakes

Wrong PATH

Cron runs with a minimal PATH, usually just /usr/bin:/bin. If your command relies on a binary in /usr/local/bin or another directory, cron will not find it. Always use absolute paths for commands:

# Wrong (may not find php)
0 * * * * php /var/www/site/script.php

# Right
0 * * * * /usr/bin/php /var/www/site/script.php

No Output Handling

By default, cron emails the output of every job to the crontab owner. If you do not have local email configured (most modern servers do not), the output goes nowhere and you never see errors. Redirect output to a log file:

0 2 * * * /path/to/backup.sh >> /var/log/backup.log 2>&1

The 2>&1 redirects error output (stderr) to the same place as standard output (stdout), so you capture both.

Overlapping Executions

If a job takes longer than the interval between runs, you can end up with multiple instances running simultaneously. This is especially dangerous for database operations. Use flock to prevent overlap:

*/5 * * * * /usr/bin/flock -n /tmp/myjob.lock /path/to/slow-job.sh

The -n flag makes flock exit immediately if the lock is already held, so the job simply skips that run.

Time Zone Confusion

Cron uses the server's system time zone. If your server is in UTC but you want jobs to run at specific times in your local time zone, you need to convert. Some cron implementations support a CRON_TZ variable:

CRON_TZ=America/New_York
0 9 * * * /path/to/command   # Runs at 9 AM Eastern

Hosted Cron Alternatives

Not every hosting environment gives you access to a server's crontab. Shared hosting, serverless platforms, and managed hosting may not support traditional cron. Hosted cron services fill this gap.

Cloud provider schedulers. AWS EventBridge (formerly CloudWatch Events), Google Cloud Scheduler, and Azure Logic Apps can trigger functions, HTTP endpoints, or queue messages on a cron schedule. These integrate with their respective cloud ecosystems.

Cron-as-a-service platforms. Services like cron-job.org, EasyCron, and Cronitor let you schedule HTTP requests to any URL. You point them at an endpoint on your site, and they hit it on the schedule you define. This works with any hosting provider because it is just an incoming HTTP request.

Platform-specific solutions. Vercel has cron jobs built into vercel.json. Netlify has scheduled functions. WordPress has WP-Cron (which runs on page loads rather than a true schedule). Laravel has its task scheduler (which requires one real cron entry to bootstrap).

For monitoring whether your cron jobs actually run (and whether they succeed), services like Cronitor, Healthchecks.io, and Dead Man's Snitch accept a ping from your cron job on each successful run and alert you if the ping does not arrive on time.

Summary

Cron is the simplest and most reliable way to automate recurring tasks on a server. The five-field schedule syntax is terse but learnable, and the most common patterns cover the vast majority of use cases. Use absolute paths, redirect output to logs, prevent overlapping executions with flock, and always test manually before deploying.

For website owners, cron jobs handle the maintenance work that keeps a site healthy: backups, database cleanup, certificate renewal, cache management, and health checks. Whether you use a traditional crontab or a hosted alternative depends on your hosting environment, but the scheduling logic is the same.