Cron Expression Parser
Parse cron expressions with human-readable descriptions and next execution times.
About Cron Expression Parser
Cron is the time-based job scheduler that has been a foundational component of Unix and Linux systems since the 1970s. A cron expression is a compact string of five space-separated fields -- minute, hour, day of month, month, and day of week -- that together define a recurring schedule. Each field accepts specific values, ranges, step intervals, and wildcards, giving administrators and developers a concise yet powerful syntax for scheduling everything from log rotation and database backups to report generation and cache invalidation. The standard crontab file, typically managed with the crontab -e command, maps these expressions to shell commands that the cron daemon executes automatically at the specified times.
The five-field format reads from left to right as: minute (0-59), hour (0-23), day of month (1-31), month (1-12 or Jan-Dec), and day of week (0-7 or Sun-Sat, where both 0 and 7 represent Sunday). Wildcards (*) match any value, commas separate lists of values (1,15 means the 1st and 15th), hyphens define inclusive ranges (Mon-Fri), and slashes specify step intervals (*/5 in the minute field means every 5 minutes). Some implementations extend this with a sixth field for seconds or special keywords like @hourly, @daily, @weekly, @monthly, and @yearly as convenient aliases for common schedules.
While cron originated as a system administration tool, its expression syntax has become a universal scheduling standard adopted far beyond Unix crontabs. Cloud platforms like AWS CloudWatch Events, Google Cloud Scheduler, and Azure Functions all use cron expressions for triggering serverless functions and workflows. Application frameworks including Spring (via @Scheduled), Quartz for Java, node-cron for Node.js, and Celery Beat for Python use the same syntax for in-process task scheduling. Kubernetes CronJobs use cron expressions to run containerized batch workloads on a schedule. Understanding cron syntax is therefore a transferable skill that applies across operating systems, cloud providers, container orchestrators, and programming languages.
How to Use the Cron Expression Parser
- Enter a 5-field cron expression into the input field using the standard format: minute, hour, day-of-month, month, day-of-week (e.g., 0 9 * * Mon-Fri).
- Read the human-readable description generated below the input to confirm the expression matches your intended schedule in plain English.
- Review the next 10 execution times displayed to verify that the schedule fires at the exact dates and times you expect.
- Examine the field-by-field breakdown table to understand how each individual field (minute, hour, etc.) contributes to the overall schedule.
- Use the preset expressions dropdown to quickly load common schedules like every minute, hourly, daily at midnight, weekly on Sunday, or monthly on the 1st.
- If the expression contains a syntax error, review the error highlighting and message to identify which field has an invalid value or format.
- Copy the validated expression for use in your crontab, CI/CD pipeline, cloud scheduler, or application configuration.
Common Use Cases
Scheduling Automated Database Backups
Database administrators use cron expressions to schedule regular backups at optimal times -- typically during low-traffic windows such as 2:00 AM on weekdays and full backups at midnight on Sundays. The expression 0 2 * * 1-5 runs at 2 AM Monday through Friday, while 0 0 * * 0 runs at midnight every Sunday. Parsing and validating these expressions before deployment prevents backup gaps caused by incorrect scheduling that might only become apparent when a restore is needed.
Triggering CI/CD Pipeline Runs
Development teams schedule nightly builds, integration test suites, and dependency vulnerability scans using cron triggers in platforms like GitHub Actions, GitLab CI, and Jenkins. An expression like 30 1 * * * runs the pipeline at 1:30 AM daily. Parsing the expression confirms the exact timing, which is important when coordinating across time zones or ensuring the pipeline completes before the team's morning standup.
Configuring Cloud Function Schedules
Serverless platforms use cron expressions to invoke functions on a recurring basis for tasks like sending digest emails, generating reports, synchronizing data between systems, or cleaning up expired sessions. An expression like 0 */4 * * * triggers a function every 4 hours. Validating the expression with a parser before deploying avoids unexpected invocation frequencies that could impact costs or downstream rate limits.
Managing Kubernetes CronJobs
Kubernetes CronJobs use cron expressions to launch containerized batch workloads for ETL processing, metric aggregation, certificate renewal, and other periodic tasks. Misconfigurations in the cron schedule field can result in jobs running too frequently (consuming cluster resources) or not at all. Parsing the expression and reviewing the next execution times before applying the manifest to the cluster catches scheduling errors during development rather than in production.
Frequently Asked Questions
What does each field in a cron expression represent?
A standard 5-field cron expression is structured as: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-7, where 0 and 7 both represent Sunday). Some systems support an optional sixth field at the beginning for seconds (0-59), extending it to a 6-field format. Each field can contain a specific value, a wildcard (*) for any value, a range (1-5), a list (1,3,5), or a step value (*/10 to mean every 10 units). The fields are evaluated together to determine matching times.
What is the difference between */5 and 0/5 in the minute field?
In most cron implementations, */5 and 0/5 in the minute field produce identical results: they both fire at minutes 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55. The */5 syntax means 'every 5 minutes starting from the field's minimum value,' and since the minute field's minimum is 0, it is equivalent to 0/5. However, 3/5 would fire at minutes 3, 8, 13, 18, 23, and so on -- starting from 3 and incrementing by 5. The distinction matters when you need the step interval to begin at a specific offset rather than the field's default starting value.
How do day-of-month and day-of-week interact?
In standard Unix cron, if both day-of-month and day-of-week are set to non-wildcard values, the job runs when either condition is met (OR logic), not when both conditions are met simultaneously. This is a common source of confusion. For example, 0 9 15 * Fri runs at 9 AM on the 15th of every month AND at 9 AM on every Friday, not only on Fridays that fall on the 15th. Some newer implementations like Quartz use AND logic instead, so it is important to check the documentation for your specific scheduler.
What do @daily, @hourly, and @weekly mean?
These are shorthand aliases defined by many cron implementations as convenience replacements for common expressions. @yearly (or @annually) is equivalent to 0 0 1 1 *, meaning midnight on January 1st. @monthly equals 0 0 1 * * (midnight on the 1st of each month). @weekly equals 0 0 * * 0 (midnight every Sunday). @daily (or @midnight) equals 0 0 * * * (midnight every day). @hourly equals 0 * * * * (the start of every hour). @reboot is a special case that runs once when the cron daemon starts. Not all systems support these aliases, so the explicit 5-field format is the most portable option.
How can I express 'every 90 minutes' in a cron expression?
You cannot express 'every 90 minutes' with a single cron expression because the minute field only supports divisors of 60. The step interval */90 is invalid since it exceeds the minute range. The closest approach is to use multiple cron entries that together approximate a 90-minute cycle: one entry for 0 0,3,6,9,12,15,18,21 * * * (every 3 hours at :00) and another for 30 1,4,7,10,13,16,19,22 * * * (every 3 hours offset by 90 minutes). Alternatively, consider using a dedicated scheduler or timer-based approach in your application code for intervals that do not align with cron's field boundaries.
Does cron account for time zones and daylight saving time?
Standard Unix cron evaluates expressions against the system's local time zone as configured in /etc/localtime or the TZ environment variable. This means cron jobs are affected by daylight saving time transitions. During a spring-forward transition, a job scheduled between 2:00 and 3:00 AM may be skipped entirely because that hour does not exist. During a fall-back transition, a job scheduled in the repeated hour may run twice. Cloud-based schedulers like AWS CloudWatch and Google Cloud Scheduler allow you to specify an explicit time zone for each schedule. For critical jobs, scheduling in UTC avoids DST ambiguity entirely.