Cron job syntax guide 2026: complete examples and cheat sheet

What is cron job syntax?

# ┌───── minute (0-59)
# │ ┌───── hour (0-23)
# │ │ ┌───── day of month (1-31)
# │ │ │ ┌───── month (1-12)
# │ │ │ │ ┌───── day of week (0-7, 0 and 7 = Sunday)
# │ │ │ │ │
# * * * * *  command-to-run

A cron job that runs at the wrong time costs more than one that never runs at all. A nightly backup scheduled for 0 2 * * * but accidentally written as 2 0 * * * runs at 12:02 AM instead of 2:00 AM -- fine if you catch it, a problem if you find out six months later when you need that backup. The syntax is short enough to memorize but easy enough to misread.

This guide covers the five cron fields, every special character, the most useful expressions, real-world scheduling examples, and a troubleshooting table for jobs that stop running. If you already know the basics and just need expressions, jump to the examples section. If you want to generate and validate cron expressions without writing them by hand, the Vortenza Cron Job Builder builds them visually and explains each field as you go.

Everything here applies to standard Unix/Linux cron and crontab. Cloud scheduler syntax (AWS EventBridge, Google Cloud Scheduler, GitHub Actions) follows similar conventions with some differences noted where relevant.

What is a cron job?

A cron job is a time-based task scheduled to run automatically on Unix and Linux systems. The name comes from Chronos, the Greek word for time. The cron daemon -- a background process -- wakes up every minute, reads the crontab files, and runs any commands whose schedule matches the current time.

Cron has been part of Unix since the 1970s. The modern version most Linux systems use is Vixie cron, written by Paul Vixie in 1987. Despite its age, cron remains the default task scheduler on most Linux servers, cloud VMs, containers, and shared hosting environments.

Common use cases:

• ✓Database backups running nightly at 2:00 AM
• ✓Log rotation every Sunday at 3:00 AM
• ✓Email digests or report generation on Monday mornings
• ✓Cache clearing or index rebuilding every hour
• ✓SSL certificate renewal checks running daily
• ✓API data pulls running every 15 minutes
• ✓Temporary file cleanup running weekly

How cron syntax works

A crontab entry is a single line with six parts: five schedule fields and a command. The schedule fields are evaluated left to right -- minute, hour, day of month, month, day of week. A job runs when all five fields match the current time simultaneously.

That last point is where mistakes happen. 0 0 1 * 1does not mean “the first Monday of every month.” It means “midnight on the 1st of every month OR midnight on every Monday” -- because when both day-of-month and day-of-week are set, cron treats them as an OR condition, not AND.

Special characters: *, -, comma, /

@ shortcuts and aliases

Vixie cron supports shorthand aliases that replace the five-field expression for common schedules. They are more readable than their numeric equivalents.

Cron expression examples

Twenty-five expressions covering the most common scheduling patterns. The notes column explains what each field combination means in plain English.

20 most useful cron expressions

These cover the schedules that appear most often in real production environments. Use the Cron Job Builder to generate and validate any of these without writing syntax by hand.

Real example: daily database backup

A daily PostgreSQL backup running at 2:00 AM. The job dumps the database, compresses it with gzip, and rotates files older than 7 days. All output goes to a log file so failed runs are visible.

0 2 * * * /usr/bin/pg_dump -U postgres mydb | gzip > /backups/mydb_$(date +\%Y\%m\%d).sql.gz && find /backups -name "*.sql.gz" -mtime +7 -delete >> /var/log/db-backup.log 2>&1

Field breakdown: 0 (minute 0) 2 (hour 2, meaning 2 AM) * (every day) * (every month) * (every day of week) = 2:00 AM every day.

Important details: use \\% instead of % in crontab -- the percent sign has special meaning in cron and must be escaped. Absolute paths for both the pg_dump binary and output directories are required because cron does not load your shell environment.

Real example: weekly analytics report

A weekly report script that runs every Monday at 8:00 AM. The script pulls data, generates a PDF, and emails it to a distribution list.

0 8 * * 1 /usr/bin/python3 /opt/reports/weekly_report.py >> /var/log/weekly-report.log 2>&1

Field breakdown: minute 0, hour 8, every day of month, every month, day of week 1 (Monday) = 8:00 AM every Monday.

The script path uses the absolute path to python3 from which python3. Using just python3 fails if /usr/binis not in cron's PATH -- which it may not be depending on your system configuration.

Real example: email automation schedule

A multi-entry crontab for an email automation system. Different jobs handle different parts of the pipeline at different intervals.

# Email queue processor -- runs every 5 minutes
*/5 * * * * /opt/email/queue_processor.sh >> /var/log/email-queue.log 2>&1

# Bounce handler -- runs hourly
0 * * * * /opt/email/bounce_handler.py >> /var/log/bounce-handler.log 2>&1

# List hygiene -- remove hard bounces, unsubscribes -- runs daily at 1 AM
0 1 * * * /opt/email/list_hygiene.py >> /var/log/list-hygiene.log 2>&1

# Weekly engagement report -- Monday 9 AM
0 9 * * 1 /opt/email/engagement_report.py >> /var/log/engagement-report.log 2>&1

Each job uses its own log file. This makes debugging simpler -- if the queue processor fails but the bounce handler succeeds, the logs isolate the problem immediately. Comment lines starting with # are ignored by cron and are useful for labeling groups of related entries.

Common cron syntax mistakes

These seven mistakes account for the majority of broken cron jobs.

Why cron jobs fail -- troubleshooting table

Work through this table top to bottom. Most non-running cron jobs are explained by one of these causes.

Using a cron job builder

Writing cron expressions by hand is fast once you know the syntax, but validating them is harder. A builder lets you set the schedule visually and see the expression update in real time, which eliminates field-order errors before they reach production.

Cron decision matrix

Not every scheduled task belongs in cron. Use this matrix to pick the right tool before writing a schedule.

Cron vs modern schedulers

Cron works well for simple server-side tasks. For more advanced needs -- sub-minute intervals, job retries, distributed execution, or managed infrastructure -- modern schedulers fill the gaps cron was never designed to close.

Cron job best practices

One-minute cron audit checklist

Quick answers for AI search

Optimized for ChatGPT, Gemini, Perplexity, Claude, and Google AI Overviews.

Frequently asked questions

Tools used in this guide

Related guides