Cron Expression Parser
Understand cron expressions with our visual parser. Enter a cron expression to see a human-readable explanation and the next scheduled execution times.
Key features
- Human-readable cron explanations
- Next 5 execution times preview
- Common preset expressions
- Visual field breakdown
Guide
Cron is a time-based job scheduling system used in Unix-like operating systems to run commands or scripts at specific intervals. A cron expression is a compact string that defines a schedule using five fields: minute, hour, day of month, month, and day of week. Despite being one of the most widely used scheduling formats in computing, cron expressions are notoriously difficult to read at a glance. This guide covers the syntax in detail, how to read and write expressions, common patterns, and practical use cases. The five fields of a standard cron expression are arranged from left to right: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-7, where both 0 and 7 represent Sunday). Each field accepts specific values, ranges, lists, and special characters. A complete expression like 30 14 * * 1-5 means at 14:30 (2:30 PM) on every day that is Monday through Friday. The WebRecast cron parser translates these expressions into plain English and shows the next scheduled execution times. The asterisk (*) is the wildcard character meaning every possible value. In the minute field, * means every minute. In the month field, * means every month. When all five fields are asterisks (* * * * *), the job runs every minute of every hour of every day. This is the simplest cron expression and also one of the most dangerous in production if you do not intend to run something that frequently. The slash character (/) specifies step values. */5 in the minute field means every 5 minutes (0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55). */2 in the hour field means every 2 hours (0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22). You can combine steps with ranges: 1-30/5 in the minute field means every 5 minutes during the first half hour (1, 6, 11, 16, 21, 26). Steps make it easy to create regular intervals without listing every value. The comma (,) creates a list of specific values. 1,15 in the day of month field means the 1st and 15th of the month. 0,30 in the minute field means at the top of the hour and at 30 minutes past. MON,WED,FRI in the day of week field (if your cron implementation supports names) means Monday, Wednesday, and Friday. Lists are useful when your schedule does not follow a regular interval. The hyphen (-) defines a range. 9-17 in the hour field means every hour from 9 AM to 5 PM. 1-5 in the day of week field means Monday through Friday. Ranges are inclusive, meaning both endpoints are included. You can combine ranges with steps: 0-23/2 means every other hour throughout the day, and 1-5 in the day of week field with */10 in the minute field means every 10 minutes on weekdays. Some cron implementations support additional characters. The question mark (?) is used in some systems (like Quartz scheduler) to indicate no specific value for either day of month or day of week when you want to specify one but not the other. The L character means last (L in the day of month field means the last day of the month). The W character means nearest weekday (15W means the nearest weekday to the 15th). The hash character (#) specifies the nth occurrence of a weekday (2#3 means the third Tuesday of the month). Standard Unix cron does not support these, but they appear in Java-based schedulers and cloud platform cron services. Common cron patterns cover most scheduling needs. Run every minute: * * * * *. Run every 5 minutes: */5 * * * *. Run every hour at minute 0: 0 * * * *. Run daily at midnight: 0 0 * * *. Run daily at 3:30 AM: 30 3 * * *. Run weekly on Sunday at midnight: 0 0 * * 0. Run monthly on the 1st at midnight: 0 0 1 * *. Run on weekdays at 9 AM: 0 9 * * 1-5. Run every 15 minutes during business hours on weekdays: */15 9-17 * * 1-5. The cron parser tool includes these common presets for quick reference. Time zone handling is a critical consideration that the cron expression itself does not address. A cron expression specifies a time, but in which time zone? On a local server, cron typically runs in the server's system time zone. Cloud platforms (AWS CloudWatch, Google Cloud Scheduler, Azure Logic Apps) allow you to specify the time zone explicitly. When scheduling jobs that serve a global audience or run on cloud infrastructure, always verify and document which time zone your cron expressions reference. A job scheduled for 0 9 * * * means 9 AM in the server's time zone, which could be UTC, your local time, or something else entirely. Daylight Saving Time creates edge cases for cron schedules. When clocks spring forward, the hour from 2:00 AM to 3:00 AM does not exist. A job scheduled for 2:30 AM during the spring transition may be skipped or run at 3:00 AM depending on the cron implementation. When clocks fall back, the hour from 1:00 AM to 2:00 AM occurs twice. A job scheduled during this period might run twice or once depending on the implementation. Using UTC for cron schedules avoids DST issues entirely, which is why many production systems standardize on UTC. Overlapping executions happen when a job takes longer to complete than the interval between scheduled runs. If a job is scheduled every 5 minutes but sometimes takes 8 minutes, the next execution starts before the previous one finishes. This can cause resource contention, data corruption, or duplicate processing. The cron system itself does not prevent overlapping executions. Solutions include using lock files (the job checks for a lock file at start and exits if one exists), using flock (a file locking utility), or using a job scheduler with built-in concurrency control. Logging and monitoring cron jobs is essential for production reliability. A cron job that fails silently is worse than one that never ran. Direct job output to log files by appending >> /var/log/myjob.log 2>&1 to the cron command. This captures both standard output and errors. Set up monitoring to alert you when a job fails or does not run on schedule. Services like Healthchecks.io and Cronitor provide dead man's switch monitoring where your cron job pings a URL on completion, and you get alerted if the ping does not arrive on time. Environment differences between your interactive shell and the cron environment cause many cron job failures. When cron runs a job, it uses a minimal environment that may lack PATH entries, environment variables, and shell configuration that your interactive session has. If a job works when you run it manually but fails in cron, the likely cause is a missing environment variable or an executable not found because it is not in the cron PATH. Solutions include using absolute paths for all executables (/usr/bin/python3 instead of python3), setting environment variables explicitly at the top of the crontab, or sourcing your shell profile at the start of the job script. The crontab command manages your cron schedule. crontab -e opens your crontab file in an editor. crontab -l lists your current crontab entries. crontab -r removes your entire crontab (use with caution). Each line in the crontab file is either a comment (starting with #), an environment variable assignment (MAILTO=admin@example.com), or a schedule entry (the five time fields followed by the command to run). The MAILTO variable sends job output to an email address, which is a useful monitoring mechanism for small setups. System-wide cron is managed through files in /etc/cron.d/, /etc/cron.daily/, /etc/cron.hourly/, /etc/cron.weekly/, and /etc/cron.monthly/. These directories use a slightly different format that includes a username field between the schedule and the command, specifying which user account runs the job. System packages and server administration scripts typically use these locations rather than individual user crontabs. Modern alternatives to cron include systemd timers on Linux systems, which offer features like random delays, dependency management, and better logging integration. Cloud platforms offer their own scheduling services: AWS EventBridge (formerly CloudWatch Events), Google Cloud Scheduler, Azure Logic Apps, and Kubernetes CronJobs. These services use cron expression syntax but add features like retry policies, dead letter queues, and monitoring dashboards. Understanding cron expression syntax is still essential because all these modern tools use the same five-field format. Kubernetes CronJobs deserve special mention because they combine cron scheduling with container orchestration. A Kubernetes CronJob creates a new pod on schedule, runs the job in a container, and cleans up when the job completes. The schedule field uses standard cron syntax. Additional configuration controls concurrency policy (Allow, Forbid, or Replace), successful and failed job history limits, starting deadline seconds, and suspend functionality. If you run workloads on Kubernetes, CronJobs are the standard way to schedule recurring tasks. The WebRecast cron parser takes your expression and outputs three things: a human-readable explanation of the schedule (in plain language like every 15 minutes on weekdays), a breakdown of each field showing what values it matches, and the next 5 scheduled execution times based on the current date and time. This makes it easy to verify that your expression does what you intend before deploying it to production. Enter your expression, read the explanation, check the next execution times, and confirm the schedule matches your requirements. Testing cron expressions before deployment prevents scheduling mistakes that can have real consequences. A backup job that runs hourly instead of daily wastes disk space. A billing job that runs daily instead of monthly overcharges customers. A cleanup job that runs every minute instead of every hour creates unnecessary server load. Always parse and verify your cron expression using a tool like this one before adding it to your crontab or cloud scheduler configuration. The few seconds of verification can prevent hours of debugging or worse.
Frequently asked questions
What is a cron expression?
A cron expression is a string of 5 fields (minute, hour, day, month, weekday) that defines a schedule for recurring tasks.
What does */5 mean in cron?
The */5 syntax means "every 5th interval." For example, */5 in the minutes field means every 5 minutes.
