Cron schedules run the invisible machinery of servers: backups at 2 a.m., reports on Monday mornings, cleanup jobs every fifteen minutes. The cost of their compact five-field syntax is that almost nobody can write or read it confidently from memory, and a single misplaced value can mean a job that runs every minute instead of every month. This builder replaces memorisation with menus. You choose how often the job should run in plain terms, and it assembles the expression for you, together with a plain-English translation you can verify before the schedule goes anywhere near a server.
Quick Answer: Choose a value for each of the five cron fields (minute, hour, day of month, month, day of week) using the menus, and the builder shows the finished expression with a plain-English explanation of when it will run.
How to Use the Cron Expression Builder
- Start from a preset if one matches your job: hourly, daily, weekly and monthly schedules are one click away.
- Adjust the minute and hour fields to set the time of day the job should run.
- Set the day of month, month and day of week fields to control which days it fires on.
- Read the plain-English explanation under the expression and check it says exactly what you intend.
- Copy the expression into your crontab, scheduler or CI configuration.
Key Features
- All five standard fields with friendly menus: specific values, ranges, steps like every 15 minutes, and wildcards.
- One-click presets for the schedules people actually use, from every five minutes to the first of the month.
- Plain-English translation of the finished expression, so mistakes are caught before deployment.
- Live expression assembly: every menu change updates the result immediately.
- Day-of-week and month names shown alongside their numbers, removing the other classic cron confusion.
Best Practices and Tips
- Remember cron uses the server's local time unless configured otherwise; a 02:00 job may run at a different UTC time than you expect.
- Day of week runs 0 to 6 with 0 as Sunday on most systems (some also accept 7 as Sunday).
- If both day-of-month and day-of-week are restricted, standard cron runs the job when EITHER matches, not both: a famous gotcha.
- Test a new schedule with a harmless job first, or set its first run a few minutes ahead and watch it fire once.
Common Mistakes to Avoid
- Reading the fields in the wrong order: minute comes first, then hour, so '0 2' is 2 a.m., not February.
- Setting a step like */15 in the hour field and expecting quarter hours: steps in hours mean every 15 hours.
- Forgetting that a wildcard month with a fixed day-of-month runs monthly, while a wildcard day-of-month with fixed weekday runs weekly.
- Scheduling heavy jobs on the hour with everyone else; offsetting minutes spreads load and avoids thundering herds.
Frequently Asked Questions
What are the five cron fields?
In order: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, Sunday first). Each field accepts a single value, a list like 1,15, a range like 9-17, a step like */10, or a wildcard * meaning every.
What does */15 in the minute field mean?
It means every fifteenth value starting from zero: minutes 0, 15, 30 and 45 of every hour. The pattern field/step always means 'every step-th value in this field'.
How do I run a job at 9:30 on weekdays only?
Minute 30, hour 9, day of month *, month *, day of week 1-5. The expression is '30 9 * * 1-5', and the builder produces it from the Weekdays preset with the time adjusted.
Does cron support seconds or yearly schedules?
Standard cron stops at minutes; seconds-level scheduling needs a different tool. Yearly jobs are expressed by fixing month and day-of-month, for example '0 0 1 1 *' for midnight on New Year's Day.
Why did my job run twice as often as expected?
Usually the day-of-month and day-of-week interaction: when both are set to specific values, cron fires when either condition matches. To require both, leave one as a wildcard and filter inside the job itself.
Related Tools
