About the Cron Expression Generator
This cron expression generator lets you fill in the five standard crontab fields — minute, hour, day of month, month and day of week — and immediately read back what the resulting schedule means in plain English. Each field accepts the usual syntax: a number, a comma-separated list, a hyphenated range, a step written with a slash, or an asterisk for every value. Alongside the expression you get a complete crontab line with output redirected to a log file, plus a reference table showing the allowed range for each position next to the value you entered. Everything is computed in your browser and nothing about your schedule is recorded.
How to use the Cron Expression Generator
- 1
Enter a Minute value: a number from 0 to 59, a list such as 0,30, a range such as 0-15, or a step such as */5.
- 2
Set the Hour field from 0 to 23 in 24-hour time, or leave it as an asterisk to run every hour.
- 3
Fill in 'Day of month' from 1 to 31, Month from 1 to 12 and 'Day of week' from 0 to 6 with Sunday as 0, leaving an asterisk where the field should not constrain the schedule.
- 4
Read the plain English summary to confirm the schedule matches what you intended.
- 5
Copy the expression, or copy the full crontab line and replace the script path with your own.
What people use it for
Scheduling a nightly backup
A database dump at minute 0 of hour 2 runs every day at two in the morning, clear of both the daily traffic peak and most deployment windows.
Running a job on weekdays only
Setting day of week to 1-5 restricts a report or a reminder to Monday through Friday so nobody receives it over the weekend.
Polling an endpoint on a short interval
A minute field of */15 runs a sync four times an hour, at 0, 15, 30 and 45 past, which is the usual pattern for a lightweight integration.
Decoding an inherited expression
Type the fields from an existing crontab entry into the tool and read the English description rather than working it out from memory.
The five fields and the day-of-month OR day-of-week quirk
A standard crontab entry has five time fields in a fixed order: minute from 0 to 59, hour from 0 to 23, day of month from 1 to 31, month from 1 to 12, and day of week from 0 to 6 with Sunday as 0, though many implementations also accept 7 for Sunday. Each field accepts a value, a list, a range, or a range with a step, of which the slash-star shorthand for the whole range is the common form. Fields are combined with AND, so every one must match for the job to run, with a single significant exception that catches almost everyone. If both day of month and day of week are restricted — that is, neither is an asterisk — Vixie cron and its descendants run the job when either field matches, not both. So an entry naming the 13th and also Friday does not mean Friday the 13th; it means midnight on the 13th of every month and also midnight every Friday. The rule is documented in the crontab(5) manual page and it is deliberate, but the safe habit is to leave one of the two fields as an asterisk unless you genuinely want the OR behaviour.
Timezones, missing hours and the schedulers that differ
System cron evaluates schedules in the server's local timezone, which means daylight saving transitions matter. When clocks go forward, jobs scheduled inside the skipped hour may not run at all; when they go back, jobs in the repeated hour can run twice. Vixie cron applies special handling for jobs scheduled within three hours of a transition, but the reliable answer is to run servers on UTC and deal with local time in the application. Cloud schedulers add their own variations. AWS EventBridge and the Quartz syntax it borrows from use six fields with seconds first, or seven with an optional year, and they add a question mark meaning no specific value in the day fields precisely to sidestep the OR ambiguity, plus L for last and W for nearest weekday. Kubernetes CronJobs use the standard five fields with an optional timezone setting. Cron also guarantees nothing about overlap: if a job runs longer than its interval the next invocation starts anyway, so use a lock file or flock where concurrent runs would cause trouble.
Tips
- Redirect both stdout and stderr as the generated line does, or cron will attempt to email you the output of every single run.
- Cron runs with a minimal environment and a short PATH, so always use absolute paths to interpreters and scripts.
- Stagger jobs across the hour rather than putting everything at minute 0 — a crowded top of the hour creates avoidable load spikes.