Cron Expression Parser
Cron expressions define schedules for recurring tasks in Unix-like systems. This tool parses cron syntax (5-7 fields), explains each field in plain English, calculates the next scheduled run times, and warns about common mistakes. Supports both user crontab format and system crontab format with user and command fields.
Specifications
Common Use Cases
- Debug why a cron job isn't running at expected times
- Understand inherited cron expressions in configuration
- Plan backup and maintenance schedules
- Verify CI/CD pipeline schedules (GitHub Actions, GitLab CI)
- Test Kubernetes CronJob schedules before deployment
- Analyze system crontab entries from /etc/crontab or /etc/cron.d/
Features
- Parse 5-field (standard), 6-field (with seconds), and 7-field (with seconds and year) cron expressions
- Support system crontab format with user field (e.g., "0 5 * * * root /path/to/script")
- Extract and display command from cron lines
- Explain each field in human-readable language
- Calculate next 10 scheduled execution times
- Support for ranges (1-5), lists (1,3,5), steps (*/15), and names (MON, JAN)
- Warn about common issues like specifying day 31 in a schedule
Examples
Tips
- The five fields are: minute (0-59), hour (0-23), day of month (1-31), month (1-12), day of week (0-6, Sunday=0).
- System crontab (/etc/crontab, /etc/cron.d/*) has a 6th field for username before the command.
- User crontabs (crontab -e) don't have a username field; they run as the crontab owner.
- Use * for "every" and */n for "every nth".
- Day names (SUN-SAT) and month names (JAN-DEC) are case-insensitive.
- Be careful with day-of-month and day-of-week together; behavior varies between implementations.
Understanding Cron Expression
Cron is the time-based job scheduler in Unix-like operating systems, and cron expressions are the compact syntax for defining when a job runs. The standard five-field format specifies minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, where 0 is Sunday). An asterisk (*) matches all values, making "* * * * *" run every minute.
Beyond simple values, cron supports several operators. Ranges (1-5) match a contiguous span. Lists (1,3,5) match discrete values. Step values (*/15) create regular intervals. These combine: 1-5/2 in day-of-week means Monday, Wednesday, Friday. Month and day-of-week fields accept three-letter names (JAN-DEC, SUN-SAT).
Cron implementations vary. User crontabs have five fields plus the command. System crontabs add a username field. Some implementations support a sixth field for seconds (Spring, Quartz, Kubernetes) and a seventh for year. AWS EventBridge, GitHub Actions, and other cloud schedulers each have their own variations.
Common pitfalls include the interaction between day-of-month and day-of-week fields: if both are specified (not *), the job runs when either condition is true (OR logic). Timezone handling is another issue — cron jobs run in the system timezone unless CRON_TZ is set, and daylight saving transitions can cause jobs to skip or run twice.
The / operator creates step values. */5 in the minute field means "every 5th minute" and produces runs at 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55 minutes past the hour. Ranges can be combined with steps: 10-30/5 means every 5 minutes between minute 10 and minute 30. To run a job at a specific time on specific days, set the minute and hour fields to the desired time and the day-of-week field to the target days. For example, "30 14 * * 1-5" runs at 2:30 PM Monday through Friday, and "0 9 * * 0" runs at 9 AM every Sunday. All times are interpreted in the server's local timezone unless CRON_TZ is explicitly configured.
Cron uses wall clock time, which means daylight saving time transitions can cause unexpected behavior. When clocks spring forward, jobs scheduled between 2:00 and 2:59 AM may be skipped entirely. When clocks fall back, jobs in that window may run twice. For critical jobs, setting CRON_TZ=UTC avoids these issues. Alternatively, avoid scheduling jobs during the transition window, or design jobs to be idempotent so that duplicate runs are harmless.
Cron syntax has been adopted well beyond Unix systems. Kubernetes CronJobs, GitHub Actions, GitLab CI, AWS EventBridge, Google Cloud Scheduler, Spring @Scheduled, and many task queue libraries all use cron expressions for scheduling. However, each implementation may support different features — some add a seconds field, some add a year field, and some use ? to mean "no specific value" in the day-of-month or day-of-week fields.