Understanding Cron Expressions and Crontab Format
A cron expression (also called crontab expression or cron job expression) is a string consisting of five fields separated by spaces. Each field represents a specific time unit that determines when your scheduled task will run. Use this cron expression translator to convert any expression to plain English. The standard cron format used in Linux, macOS, Kubernetes CronJobs, and GitHub Actions follows this pattern:
┌───────────── minute (0-59)
│ ┌───────────── hour (0-23)
│ │ ┌───────────── day of month (1-31)
│ │ │ ┌───────────── month (1-12)
│ │ │ │ ┌───────────── day of week (0-6, Sunday=0)
│ │ │ │ │
* * * * * command_to_execute
Cron Special Characters Explained
Asterisk (*) - Every Value
The asterisk matches every possible value for a field. For example, * in the hour field means "every hour," and * in the day of month field means "every day."
Comma (,) - List of Values
Use commas to specify multiple discrete values. For example, 1,15 in the day field runs the task on the 1st and 15th of each month. Similarly, 0,6 in the weekday field targets Saturday and Sunday.
Hyphen (-) - Range of Values
The hyphen creates a range of values. For example, 9-17 in the hour field means "every hour from 9 AM to 5 PM," and 1-5 in the weekday field means "Monday through Friday."
Slash (/) - Step Values
The slash defines step values (intervals). */15 in the minute field means "every 15 minutes," while */2 in the hour field means "every 2 hours." You can combine this with ranges: 0-30/5 means "every 5 minutes during the first half hour."
Cron Across Different Platforms
Linux Crontab
The original cron implementation on Linux and Unix systems. Edit your personal crontab with crontab -e and view scheduled jobs with crontab -l. System-wide cron jobs are typically stored in /etc/cron.d/.
Kubernetes CronJobs
Kubernetes uses the same 5-field cron syntax to schedule Jobs. CronJobs run in containers and are ideal for scheduled batch processing, database backups, and periodic cleanups in a containerized environment.
GitHub Actions
GitHub Actions workflows can be triggered on a schedule using cron syntax. Note that GitHub schedules run in UTC timezone, and there may be delays during high-load periods. The syntax is placed in your workflow YAML under on: schedule: - cron:.
AWS CloudWatch Events / EventBridge
AWS supports cron expressions with a 6-field format (adding a year field) for scheduling Lambda functions and other AWS resources. The syntax is slightly different, so verify expressions when migrating.
Common Cron Mistakes to Avoid
- Timezone confusion: Cron typically uses the server's timezone. Always verify which timezone your cron daemon uses, especially on cloud servers that may default to UTC.
- Overlapping day constraints: When you specify both day-of-month and day-of-week, cron runs when either matches, not both. This can lead to unexpected executions.
- Missing path environment: Cron runs with a minimal environment. Always use absolute paths for scripts and binaries, or set PATH at the beginning of your crontab.
- No output handling: By default, cron emails output to the user. Redirect output to a log file or
/dev/null to prevent mail buildup.
- Permission issues: Ensure scripts are executable (
chmod +x) and the cron user has permission to access all required files.
Cron Best Practices
- Log everything: Redirect output to log files for debugging. Example:
0 2 * * * /path/to/script.sh >> /var/log/myjob.log 2>&1
- Use lock files: Prevent overlapping executions with flock:
flock -n /tmp/myjob.lock /path/to/script.sh
- Test expressions: Use this tool to verify your cron expressions before deploying them to production.
- Stagger execution times: Avoid scheduling multiple jobs at exactly :00 minutes. Spread them out to reduce system load spikes.
- Monitor job execution: Use monitoring tools to alert when scheduled jobs fail or don't run as expected.