Cron Jobs Explained: The Developer's Complete Guide to Task Scheduling

Every production server has a hidden heartbeat. It wakes up at midnight, runs your database backups, cleans up temp files, sends your weekly report emails, and goes back to sleep — without you ever touching a keyboard. That heartbeat is called cron. And if you are deploying to any Linux/Unix server and don't understand it deeply, you are leaving a massive automation superpower on the table.

In this guide, we will dissect every part of a cron expression, show you 10 real-world scheduling patterns, expose the 5 mistakes that will burn you in production, and teach you how to debug cron jobs like a seasoned sysadmin. You can also use our free Crontab Generator to build and validate any expression visually without memorizing the syntax.

1. The Cron Syntax: All 5 Fields Explained

A cron expression is a string of five fields separated by spaces. Each field controls a unit of time. Together they define a precise, repeating schedule.

2. Special Characters: The Powers Behind the Schedule

The asterisk * is just the beginning. Cron's real flexibility comes from four special characters that let you express complex schedules in a single string.

• *
  Asterisk — "Every"Matches all possible values. * * * * * means "every minute of every hour of every day."
• ,
  Comma — "And"Specifies a list. 0 9,12,18 * * * runs at 9 AM, noon, and 6 PM daily.
• -
  Hyphen — "Through"Defines a range. 0 9-17 * * 1-5 runs at the top of every hour, Monday through Friday, 9 AM to 5 PM.
• /
  Slash — "Every N-th"Specifies step intervals. */15 * * * * runs every 15 minutes. 0 */6 * * * runs every 6 hours.

3. @Macros: The Shorthand Commands

Most modern cron implementations support @macros — human-readable shortcuts that replace the 5-field syntax entirely. They are especially useful for common schedules.

4. 10 Real-World Cron Job Examples

Theory is one thing. Here are the scheduling patterns you will actually encounter in production systems.

5. The 5 Most Common Cron Job Mistakes (And How to Fix Them)

Cron issues are notoriously silent and frustrating to debug. These are the five traps that catch nearly every developer at least once.

• 1
  Wrong Working Directory

  Cron does not inherit your shell's current directory. If your script does require '../config.php', it will fail silently because cron runs from / or the user's home directory. Fix: Always use absolute paths, or set cd /path/to/project && before your command.

• 2
  Missing Environment Variables

  Cron uses a minimal environment — no PATH, HOME, or custom env vars you set in .bashrc. Commands like php or python3 may not be found. Fix: Use the full binary path (e.g., /usr/bin/php or /usr/local/bin/python3), or set PATH at the top of your crontab.

• 3
  No Output Logging

  By default, cron emails output to the system. If mail is not configured, all output is silently discarded. You will never know if your job failed. Fix: Redirect output: * * * * * /path/to/script.sh >> /var/log/myjob.log 2>&1

• 4
  Overlapping Job Runs

  Cron does not know if the previous run of a job is still executing. A job scheduled every minute that takes 90 seconds will have two instances running simultaneously, potentially corrupting data. Fix: Use flock: * * * * * flock -n /tmp/myjob.lock /path/to/job.sh

• 5
  DST and Timezone Confusion

  Cron runs in the system's timezone by default. Daylight Saving Time transitions can cause a job to run twice (or not at all) at 2 AM. Fix: Set an explicit timezone in your crontab using CRON_TZ=UTC at the top of the file, or use UTC for all critical jobs.

6. How to Monitor and Debug Cron Jobs

Debugging cron is all about making the invisible visible. Here is your debugging toolkit.

View Cron Logs

On Debian/Ubuntu systems, cron logs to syslog. View them with:

# View recent cron executions
grep CRON /var/log/syslog | tail -50

# Or on systems using journald
journalctl -u cron --since "1 hour ago"

Redirect Output to a Log File

The simplest and most reliable debugging method — always log stdout and stderr:

# Redirect both stdout and stderr to a timestamped log
*/5 * * * * /usr/bin/php /var/www/job.php >> /var/log/cron_job.log 2>&1

# Prepend timestamps using ts from the moreutils package
*/5 * * * * /usr/bin/php /var/www/job.php 2>&1 | ts >> /var/log/cron_job.log

Use MAILTO for Error Alerts

Set a MAILTO variable at the top of your crontab to receive email on any output:

MAILTO=admin@yoursite.com

# Job output will be emailed if it produces any output
0 2 * * * /usr/bin/php backup.php

Test Your Command Manually First

Before scheduling anything, run the exact command as the cron user (usually root or www-data) to ensure it works in the same environment:

# Test as the www-data user (common for web server crons)
sudo -u www-data /usr/bin/php /var/www/html/job.php

Frequently Asked Questions