Somewhere on nearly every server, a small scheduler wakes up once a minute, reads a list of jobs, and runs the ones whose time has come. Backups, report emails, cache clearing, log rotation and data synchronisation all tend to live there. The schedule for each job is written as a cron expression: five fields, separated by spaces, standing for minute, hour, day of the month, month and day of the week. The format is compact and powerful, and it is also easy to get wrong, because a single misplaced asterisk changes the meaning completely. The Cron Expression Generator lets you build an expression from plain fields and read back what it means, so you can check the schedule before it ever reaches a server.
Each field accepts a small vocabulary. An asterisk means every value in that field: every minute, every hour, every day, and so on. A single number means exactly that value. A comma-separated list means several values, such as 1,15 for the 1st and 15th. A range with a hyphen means a span, such as 1-5 for Monday through Friday in the day-of-week field. A step with a slash means every nth value, such as every 15 minutes. These pieces can be combined, but they should be combined sparingly. An expression that only its author can read is a maintenance problem waiting for the day that author is unavailable.
How the tool works
You fill in the five fields in plain form, choosing minutes, hours, days, months and weekdays, and the tool assembles the expression and states its meaning in ordinary language. Everything runs in your browser, so nothing is scheduled or changed on any server by using it. That separation is important: generating an expression is a planning step, and installing it on a server is a separate step that you should do deliberately, in the right file, with a test afterwards. The tool's job is to make sure the expression you install is the expression you meant.
The field order is the single most important thing to memorise: minute first, then hour, then day of the month, then month, then day of the week. Many cron mistakes come from assuming the order starts with the hour, or from writing a day-of-week value where a day-of-month value belongs. The ranges help you sanity-check yourself. Minutes run from 0 to 59, hours from 0 to 23, days of the month from 1 to 31, months from 1 to 12, and days of the week from 0 to 7, where both 0 and 7 mean Sunday in most implementations. If a value falls outside its field's range, something is wrong, no matter how reasonable the expression looks.
A worked example
Suppose you want a job to run at 9 in the morning every Monday. The minute is 0, the hour is 9, the day of the month is unrestricted, the month is unrestricted, and the day of the week is 1, since Monday is day 1 when Sunday is day 0. The expression is therefore 0 9 1, which reads as "at 09:00 on Monday". Each asterisk means "every" for its field, so the day of the month and the month impose no restriction, and the job runs on every Monday of every month.
A second example shows a weekday pattern. To run a job at half past eight on weekdays, the minute is 30, the hour is 8, the day of the month and month are unrestricted, and the day of the week is the range 1-5, Monday through Friday. The expression is 30 8 1-5, which reads as "at 08:30, Monday through Friday". Notice that the range sits in the weekday field only. Putting 1-5 in the day-of-month field instead would mean the 1st through 5th of each month, a completely different schedule that would still look plausible at a glance. Reading the expression back in plain language is the check that catches that kind of slip.
Common mistakes
The most famous cron mistake is combining day-of-month and day-of-week restrictions and expecting both to apply. In classic cron, when both fields are restricted, the job runs when either condition matches, not both. Writing a schedule that means "the 15th, but only if it is a Monday" is therefore not possible with those two fields alone; you need a different mechanism, such as a check inside the job itself. A second mistake is forgetting that cron runs in the server's timezone, which may not be your timezone. A job scheduled for 9 in the morning on a server set to a different timezone will run at 9 in that timezone, not yours, and daylight saving changes can shift it further.
A third mistake is scheduling jobs too close together or overlapping. A job that takes ten minutes but is scheduled every five minutes will pile up overlapping copies, each competing for the same resources. A fourth mistake is writing expressions that look right but use out-of-range values, such as an hour of 24 or a weekday of 8, which some implementations reject and others interpret unpredictably. A fifth mistake is never testing: a job scheduled for the 31st of the month will simply not run in shorter months, and a job scheduled for a weekday that never arrives in a given month will sit silently. Check the next few run dates before you consider a schedule finished.
Honest limitations
A generator builds expressions; it does not run jobs, watch them, or warn you when they fail. It cannot know your server's timezone, your cron implementation's quirks, or whether a job is safe to run twice if a previous run overlaps. Some systems extend cron with extra fields, such as seconds, or with special strings, and a five-field generator does not cover those variants. The plain-language reading it gives you is a check on your intent, not a guarantee that every cron implementation will interpret the expression identically. After generating an expression, install it carefully and confirm the first runs happen when expected.
Closing
Cron rewards a slow, deliberate minute of checking. Fill in the fields, read the expression back in plain language, and confirm the next run dates match your intent. A schedule that says "Monday at 09:00" when you meant "weekdays at 08:30" is a bug that only reveals itself weeks later, when the report never arrives. For neighbouring jobs, the Time Converter helps with timezone arithmetic and the UUID & ULID Generator covers unique identifiers for jobs and records, while How to Format and Validate JSON helps when a scheduled job produces data you need to inspect.