⏰ Cron Expression Parser
Parse cron expressions into human-readable descriptions and explore common schedule presets.
HUMAN DESCRIPTION
At 09:00, every day of month, every month, day 1-5
Minute
0-59
Hour
0-23
Day of Month
1-31
Month
1-12
Day of Week
0-7
Common Presets - click to load
📊 Key Data Points
5 fields
minute hour day month weekday — each with its own modifier syntax
Next 10 runs
Execution preview shows exactly when the job will run — in both UTC and local time
@shortcuts
@daily, @weekly, @monthly etc. are supported and converted to their 5-field equivalents
Cron Expression Builder -- Complete USA Guide 2026
Cron syntax has five fields — minute, hour, day-of-month, month, day-of-week — each with its own special characters. A misplaced character schedules your job at 3am instead of 3pm, or runs it every minute instead of once a day.
This builder converts human-readable schedules to cron expressions and back. Shows the next 10 execution times so you can verify the schedule is correct before deploying. Runs in your browser.
**Long-tail searches answered here:** build cron expression visually with next run times, cron job every 5 minutes syntax online, how to write cron expression for first Monday of month.
Pair with Timezone Converter for server timezone differences.
🔬 How This Calculator Works
The builder maintains a cron expression string and updates it as you select schedule options. It also accepts a raw cron expression and parses it back to human-readable form.
The execution preview calculates the next 10 run times from now, formatted in both UTC and your local timezone — the key validation step, since many cron bugs are timezone issues.
Supported syntax: standard 5-field cron plus common extensions: @hourly, @daily, @weekly, @monthly, @yearly, @reboot.
✅ What You Can Calculate
Next 10 execution times
See exactly when your job will run next — actual timestamps in both UTC and local time. Catches am/pm mistakes and timezone confusion before they cause production incidents.
Human-to-cron and cron-to-human
Type a cron expression to get a plain English description, or describe a schedule in plain English to get the cron syntax.
Special character reference
L (last), W (nearest weekday), # (nth weekday) and step values (/5) are all supported and explained inline.
Timezone-aware preview
Preview shows times in both UTC and your local timezone. Most servers run UTC; most developers think in local time. Seeing both prevents the classic why did my job run at 2am problem.
🎯 Real Scenarios & Use Cases
Database backup scheduling
You want a nightly database backup at 2am server time. Enter the schedule here and verify the next run times before adding it to your crontab or Kubernetes CronJob manifest.
First Monday of the month
Business reports that run on the first Monday of each month require the # day-of-week modifier. Build it here and verify the actual dates.
API rate-limited polling
You need to poll an API every 15 minutes but avoid peak hours (9am-5pm). The builder shows how to combine step values with hour ranges.
Kubernetes CronJob specs
Kubernetes CronJob schedules use standard cron syntax. Build your schedule here, verify the next run times, then paste the expression into your CronJob manifest.
💡 Pro Tips for Accurate Results
Verify timezone before deploying. Your cron expression runs on the server clock, which is almost always UTC. If you want a job at 9am New York time, that is 14:00 UTC (EST) or 13:00 UTC (EDT). The preview shows both — use Timezone Converter if unsure.
Step values start at 0. */5 means 0, 5, 10, 15... The first run after deploy might be in less than 5 minutes depending on the current minute.
L for last day. L in the day-of-month field means the last day of the month. This is a cron extension — not all cron implementations support it. Verify your target scheduler supports it.
Test with shorter intervals first. When deploying a new scheduled job, set the interval to every 2 minutes, verify it runs correctly, then change to the real schedule.
🔗 Use These Together
🏁 Bottom Line
Cron expressions are unforgiving — a single wrong field runs your job at the wrong time, and most cron systems do not validate expressions before the first scheduled run. This builder prevents those errors by showing the actual next execution times before you deploy.
For containerized scheduling: build your expression here, configure with Docker Compose Generator, and account for timezone differences with Timezone Converter.
What do the five fields in a cron expression mean?
A standard cron expression has five fields: [minute] [hour] [day-of-month] [month] [day-of-week]. Each field accepts: a specific value (5 = 5th minute), a range (1-5 = 1 through 5), a list (1,3,5 = 1st, 3rd, 5th), a step (*/15 = every 15 units), or * (any value). Example: 30 9 * * 1-5 means 'at 9:30 AM, every day, Monday through Friday'. 0 0 1 * * means 'midnight on the 1st of every month'. The order is counterintuitive — minute comes before hour.
What is the difference between 5-field cron and 6-field cron with seconds?
Standard Unix cron uses 5 fields (minute, hour, day, month, weekday) — minimum resolution is 1 minute. Some systems add a 6th field for seconds at the beginning: [second] [minute] [hour] [day] [month] [weekday]. Spring Framework's @Scheduled and Quartz Scheduler use the 6-field format. AWS EventBridge and Linux cron use 5-field. If you configure a cron job and it runs at unexpected times or throws a syntax error, check whether the system expects 5 or 6 fields.
What do @weekly, @daily, and @reboot mean?
String aliases for common patterns: @reboot runs once at startup, @yearly = 0 0 1 1 * (midnight January 1st), @monthly = 0 0 1 * * (midnight on the 1st), @weekly = 0 0 * * 0 (midnight Sunday), @daily = 0 0 * * * (midnight every day), @hourly = 0 * * * * (top of every hour). Supported in Vixie cron (standard on most Linux systems) but not all cron implementations — check your environment's documentation before relying on them.
How do I schedule a job to run every 15 minutes?
Use */15 in the minute field: */15 * * * * runs at :00, :15, :30, and :45 of every hour. For only during business hours: */15 9-17 * * 1-5 (every 15 minutes, hours 9-17, Monday-Friday). The step syntax */n means 'starting from 0, every n units'. You can also start from a different point: 5/15 * * * * starts at :05 then :20, :35, :50. One common mistake: 0,15,30,45 * * * * is equivalent but more explicit and works in systems where step syntax may not be supported.
Why does cron use the server timezone?
The cron daemon runs in the server's system timezone. If your server is UTC and you want a job at 9 AM Eastern (UTC-5 in winter), set the cron for 14 * * * *. The problem: daylight saving shifts change the offset seasonally, so a 9 AM Eastern job needs to be hour 13 or 14 depending on time of year. Solutions: (1) Set the entire server to UTC and handle timezone conversion in the application, (2) Use a cron system that supports TZ environment variables per-job, (3) Use a cloud scheduler like AWS EventBridge that accepts timezone-aware cron expressions.
How do I debug a cron job that is not running?
Most common reasons: (1) The crontab is not installed — verify with crontab -l. (2) The script does not have execute permission — chmod +x your script. (3) Environment variables are not set — cron runs with a minimal environment, no PATH customization; use absolute paths to commands. (4) Output is being swallowed — redirect stdout and stderr: */5 * * * * /path/to/script.sh >> /var/log/myjob.log 2>&1. (5) The script exits with an error due to missing env vars in the bare cron environment.
What other infrastructure tools pair with the Cron Generator?
The chmod Calculator handles execute permissions for cron scripts. The Unix Timestamp Converter helps interpret timestamps in cron job logs. The Diff Checker reviews script changes before cron deployment. The Bandwidth Calculator estimates run time for cron jobs involving file transfers or backups. All are in the Dev Tools section.