Cron Expression Generator: Who It's For and How to Use It
Reviewed by the FreeOnline.fyi team · Updated
Key points
- Cron Expression Generator turns a visual five-field schedule into standard, Quartz and AWS EventBridge cron strings at once.
- It is free, needs no login, and runs entirely in your browser, so no schedule data leaves your machine.
- Every schedule shows a plain-English description plus the next five fire times in your timezone and in UTC.
- Standard cron ORs day of month and day of week when both are restricted, a rule that surprises most people.
- Quartz numbers days of the week 1 = Sunday, while standard cron uses 0 or 7 for Sunday.
Who benefits from a cron expression generator?
Cron Expression Generator is a browser-based cron builder that turns a visual five-field schedule into a valid cron string for standard crontab, Quartz and AWS EventBridge Scheduler, together with a plain-English description and the next five fire times in your timezone.
The people who get the most out of it are backend and platform developers, DevOps engineers and data engineers wiring up GitHub Actions workflows, Kubernetes CronJobs, EventBridge Scheduler rules or Spring and Quartz jobs. Cron syntax is only five fields wide, but the failure modes are loud: a typo that moves a job from 09:00 to 21:00, or a step value that fires something every minute instead of every hour.
We built Cron Expression Generator as a single screen because the usual loop is scattered — write an expression, guess what it means, deploy, then wait to find out. Clicking the chips, reading the generated string and checking the next run times takes seconds and replaces that guesswork.
How do you read a five-field cron expression?
A standard cron expression has five space-separated fields, always in this order: minute, hour, day of month, month, day of week. The tool's default is 0 9 * * *, which means daily at 09:00 — minute 0, hour 9, and every day of every month.
Each row in the builder offers the same choices: * for every value, a plain integer like 30, a step such as */5 or */15, a range like 9-17, a list like 1,15,30, and named values for months (JAN-DEC) and weekdays (SUN-SAT). Anything you click is reflected immediately in the expression and in the English description underneath.
The rule that catches almost everyone is the day fields. In standard cron, when day of month and day of week are both restricted rather than *, the job runs when either one matches. So 0 0 13 * 5 fires on the 13th of the month and on every Friday, not only on Friday the 13th.
Paste an existing expression and edit it visually
Most real work starts with a schedule someone else wrote. The paste box accepts a five-field crontab string, a six- or seven-field Quartz expression, or a macro such as @daily, @hourly, @weekly, @monthly or @yearly, and parses it back into the visual selector so you can edit it by clicking rather than by counting spaces.
If the input does not parse, the tool shows a field-level error inline and leaves your current schedule untouched. That behaviour is deliberate: an expression that looks plausible but fires at the wrong time is far more dangerous than one that is rejected outright.
This is the fastest way to answer the question that comes up in code review — what does this line in the crontab actually do, and is it still what we intended when it was written? The same page, along with the rest of FreeOnline.fyi free online tools, runs entirely in the browser with no login.
One schedule, three cron dialects
The same intent is written differently depending on where it runs, and copy-pasting between platforms is a common source of silent bugs. Cron Expression Generator outputs your schedule under three tabs so you can compare them side by side.
Standard is the five-field form used by Linux crontab, GitHub Actions and Kubernetes CronJobs. Quartz adds a leading seconds field for Spring and Java schedulers. AWS EventBridge Scheduler uses six fields ending in a year field, requires ? in one of the two day fields instead of *, and does not accept every wildcard pattern that Linux cron does — the AWS EventBridge Scheduler schedule types documentation spells out the limits.
Weekday numbering is the trap here. Standard cron treats 0 or 7 as Sunday and 1 as Monday, while Quartz numbers 1 as Sunday through 7 as Saturday. A schedule moved from a Quartz app into a crontab without adjusting that field can run a day late.
Next fire times in your timezone and UTC
Timezones are where cron quietly breaks. The timezone selector is pre-filled from your browser, and every result also shows the UTC equivalent, because Kubernetes CronJobs, GitHub Actions runners and EventBridge Scheduler execute in UTC by default.
Concrete example: */15 9-17 * * 1-5 fires every 15 minutes from 09:00 through 17:45 on weekdays — 36 runs per weekday, 180 per week. That looks harmless in local time, but if the scheduler runs in UTC and you sit three hours behind it, your "business hours" job actually starts at 06:00 local.
Daylight saving is the second trap. A job set for 02:30 daily can be skipped entirely on a spring-forward date in DST-observing regions, and a fixed UTC schedule drifts an hour against local wall-clock time twice a year. Use the next-five-runs list as a sanity check, then confirm anything critical against your scheduler's own documentation.
Cron mistakes this tool helps you catch
Two numbering schemes are worth memorising. Months in cron are 1-12, not 0-11 as in most date libraries, so January is 1 and December is 12. Days of the week in standard cron run 0-6 with 0 and 7 both meaning Sunday, while Quartz runs 1-7 starting at Sunday.
Other easy slips: 0 0 31 * * only fires in the seven months that have a 31st; a plain integer means exactly that value, so 5 in the minute field is minute five of every hour, not every five minutes; and ranges combined with steps, like 0-30/10, behave as 0,10,20,30 rather than as a plain step across the hour.
Macros are a shorthand you should be able to expand by hand. @daily is 0 0 * * *, @hourly is 0 * * * *, @weekly is 0 0 * * 0, @monthly is 0 0 1 * * and @yearly is 0 0 1 1 *. If a job refreshes data — an exchange-rate table, say, like the one behind our Live Currency Converter — verify the fire time against the data provider's own update schedule before trusting it.
Frequently asked questions
Is Cron Expression Generator free, and do I need an account?
Cron Expression Generator is free and requires no account, login or email. The schedule builder, dialect conversion, plain-English description and next-five-runs list all run inside your browser, so nothing you type is uploaded to a server. That also means it keeps working once the page has loaded, even on locked-down workstations where installing packages is not an option.
Does Cron Expression Generator show next run times in my local timezone?
Yes. The timezone selector is pre-filled from your browser's IANA timezone, such as Europe/Berlin or America/New_York, and the next five fire times are listed in it. Because Kubernetes CronJobs, GitHub Actions and EventBridge Scheduler run in UTC by default, every result also displays the UTC equivalent so you can compare before deploying.
Can Cron Expression Generator convert an existing crontab into Quartz or AWS EventBridge format?
Yes. Paste a five-field crontab entry, a six- or seven-field Quartz expression, or a macro such as @daily into the paste field. The tool parses it back into the visual selector, and the output tabs let you copy the same schedule as standard five-field cron, Quartz with seconds, or AWS EventBridge Scheduler syntax with a year field.
What happens if I paste an invalid cron expression?
The tool reports a field-level error inline and leaves your current schedule untouched, so a bad paste cannot silently wipe work you have already built. This is intentional: an expression that still looks plausible but fires at the wrong time is more dangerous than one that is rejected outright, because it can reach production unnoticed.
Does Cron Expression Generator handle daylight saving time?
It calculates the next five fire times as a scheduler would in the timezone you select, including DST transitions. It does not rewrite your expression: a fixed UTC schedule drifts an hour against local wall-clock time twice a year, and a job set for 02:30 may be skipped on a spring-forward date. Confirm critical schedules with your scheduler's own documentation.