Cron expression generator

What a cron expression generator has to decide before it can answer

Five or six numbers separated by spaces look like one notation, and they are two. Before anything can be said about 0 0 12 * * ? — what it means, when it runs next, whether it is even legal — a reader has to know which set of rules is in force. Under Quartz that string is noon every day. In a Unix crontab it is a syntax error, because crontab has five fields and no question mark. Turn it around and 0 12 * * 5 is Friday at noon in a crontab and is not a Quartz expression at all.

Most tools resolve this by counting fields and picking a syntax for you. That is right often enough to be trusted and wrong often enough to be dangerous, and the failure is not an error message — it is a confident, readable, wrong sentence about a schedule you are about to deploy. So the syntax here is two buttons that are always visible, it never changes on its own, and when you paste six fields into Unix mode the message says that six fields is Quartz and offers the switch instead of taking it. Switching modes leaves your expression alone and reads it again under the other set of rules, which is the whole point of having both in one place.

The weekday numbers disagree, and that is the quiet one

The field-count difference announces itself: get it wrong and something refuses to parse. The numbering difference does not. A Unix crontab counts Sunday as 0 and also accepts 7 for it, so Monday is 1 and Friday is 5. Quartz counts Sunday as 1, so Monday is 2 and Friday is 6. Every weekday number in a Quartz expression is one higher than the crontab number for the same day.

Copy a weekday out of a Stack Overflow answer written for the other scheduler and nothing breaks. The expression parses. It deploys. It runs — one day late, every week, until somebody notices that the Monday report is landing on Tuesday. Because the two dialects are separate modes here, each number is read under its own rules and the description names the day in words rather than repeating the digit back at you. When a schedule can be carried across, the translated expression is printed in full before you accept it, and the note says which numbers moved and why. When it cannot be carried across, the reason is named and no expression is offered.

L, LW, nW and n#N — the schedules a crontab cannot express

Quartz has vocabulary that plain cron lacks, and it exists because real schedules need it. L in the day-of-month field is the last day of the month, whatever length that month happens to be, so it lands on the 28th, 29th, 30th or 31st as the calendar requires. L-3 is three days before that. LW is the last weekday of the month, which is where payroll, invoicing and month-end reporting actually belong, because the 31st is a Sunday roughly one month in seven. 15W is the weekday nearest the 15th without crossing into another month.

In the day-of-week field the same letters mean something else: 6L is the last Friday of the month and 6#3 is the third Friday. None of these exist in a Unix crontab, and there is no clever way to fake them — the honest workaround is to schedule the job every day and let the script itself decide whether today is the right day. This page therefore accepts them only in Quartz mode, says so plainly rather than calling them invalid, and refuses to translate them into a crontab that would mean something else.

Next run times are meaningless without the zone written next to them

A cron expression carries no time zone. It describes wall-clock time in whatever zone the machine or the scheduler is configured for, which means the same five fields fire at four different instants depending on where they are installed. A list of upcoming runs with no zone printed beside it is not an answer; it is a set of numbers that happens to look like one.

So the zone is named above the list, it starts as your own computer's zone as the browser reports it, and you can change it to UTC or to any IANA name your browser knows. Each run shows the UTC offset that was actually in force at that moment, which is what makes daylight saving visible instead of silent: a 2:30 AM job in a zone that springs forward has one day a year when 2:30 AM does not exist, and that run is flagged rather than quietly listed as though it were ordinary. Worth checking on the other side too — Quartz triggers can carry their own TimeZone, and Unix cron reads CRON_TZ or falls back to the system zone. If what you are actually holding is an epoch integer out of a log rather than a schedule, the Unix timestamp converter is the narrow tool for that, and it makes the same point about offsets from the other direction.

The OR rule between the two day fields

In a Unix crontab, 0 0 13 * FRI does not mean Friday the 13th. When both the day-of-month and the day-of-week fields are restricted, Vixie cron treats them as OR rather than AND: the job runs on the 13th of every month and on every Friday, which is five or six times a month instead of once or twice a year. The rule is genuinely in the crontab manual and it surprises people who have been writing cron entries for years. It only applies when neither field is a star — restrict just one and it behaves the way you expect.

The next run times on this page follow that rule and say so on screen, rather than computing something more intuitive and less true. Quartz sidesteps the question entirely by requiring a ? in one of the two day fields, which is also why an expression that restricts both cannot be carried from a crontab into Quartz at all: there is nothing in Quartz that means what cron means there.

Where these expressions usually live

Very few cron expressions are typed into a crontab any more. They arrive in a Kubernetes CronJob, a GitHub Actions schedule block, an Airflow DAG or a docker-compose sidecar — which means the string you are debugging is usually one quoted line inside a larger file. If the surrounding file is what is confusing you rather than the five fields, the YAML to JSON converter will show you the structure the scheduler actually receives, and the JSON formatter does the same for an EventBridge rule or a job definition that arrived on one long line. Comparing a crontab against the one that was running last week is a diff, not a parse, and the text comparison tool is the better instrument for that.

Note that those platforms are not all the same cron. AWS EventBridge uses six fields with a year at the end and requires a ? like Quartz. Kubernetes uses standard five-field cron. Spring's scheduler uses six fields with seconds first but numbers days the Unix way. This page implements the two that the vast majority of expressions are written in and does not pretend to cover every scheduler's local variation — a tool that claimed to would be guessing again, one layer up.

When an expression cannot be read

“Invalid expression” tells you nothing you did not already know. Every failure here carries a line number, a character position, a caret under the exact token that failed, the name of the field it belonged to, and what that field accepts. A backwards range says it is backwards and shows you two ways to write it that are not ambiguous. A weekday number outside the dialect's range says which numbering each dialect uses. A ? in Unix mode is told that crontab has no question mark rather than being called a syntax error. A whole crontab line pasted in — schedule, command and arguments — has its command set aside out loud, because that line is correct and rejecting it would be the tool's mistake, not yours.

Why none of this is sent anywhere

Reading five to seven whitespace-separated tokens is string work, and the next run times are integer arithmetic over calendar fields. The whole calculation finishes in well under a millisecond on the machine you are already using, so there is no server to ask and none was built. Nothing you type is uploaded, appended to the address bar where it would survive in your history, written to browser storage, or logged.

That is not only a privacy point, though a cron expression sitting next to a command line often names internal hosts, paths and scripts. It is a durability point. The tool this page replaces put both the plain-English reading and the next execution dates on a server, and when that site went dark in 2026 the answer went with it — every link to it, from Atlassian's documentation on down, now returns a 404. A page that computes its own answer keeps working for as long as your browser does. If you would rather confirm that than take it on trust, the guide to verifying local processing shows how to watch the network panel stay empty while you type.