Cron Expression Generator & Explainer

Cron Expression Generator & Explainer

What a cron expression is

A cron expression is a compact schedule made of five fields: minute, hour, day of month, month and day of week. A server reads those fields and runs a task when they match the current time. The format is powerful but easy to misread, especially around day-of-month and day-of-week rules. This page helps you build a schedule, explains it in plain English and shows the next run times.

The five fields

The fields run from left to right: minute (0–59), hour (0–23), day of month (1–31), month (1–12) and day of week (0–6 or SUN–SAT). An asterisk means every value. A number means that exact value. A comma lists several values. A hyphen gives a range. A slash gives a step, such as every five minutes. The page works with standard five-field cron, not Quartz six- or seven-field syntax.

Using the schedule builder

Choose a schedule type from the menu: every minute, every N minutes, hourly, every N hours, daily, twice daily, weekly, monthly, weekdays, weekends or a custom expression. Set the time, interval, weekday or day of month where the form asks for it. The builder writes the expression for you. You can also type a custom expression into the explainer and read the field-by-field breakdown.

Common schedules

`* * * * *` runs every minute. `*/15 * * * *` runs every fifteen minutes. `0 9 * * *` runs at 09:00 every day. `0 9 * * 1-5` runs at 09:00 Monday through Friday. `0 0 1 * *` runs at midnight on the first day of each month. `0 9,21 * * *` runs at 09:00 and 21:00. These examples assume the server's timezone, which the expression itself does not specify.

Reading the plain-English explanation

The explainer converts the expression into a sentence such as “At 09:00 AM, Monday through Friday.” It also breaks down each field and shows the next run times. The description is a convenience, not a guarantee. Complex expressions with both day-of-month and day-of-week restrictions can behave differently across cron implementations. Check the next-runs list and your server's documentation.

Next run times

The next-run panel uses a cron parser to list upcoming executions. You can request between 1 and 50 results; the default is 10. The list is useful for catching a timezone mistake or an impossible date such as 31 February. It is calculated from the current time, so reload or regenerate after changing the expression. The page does not know your server's timezone unless you interpret the times in that zone.

Timezone and daylight saving

A cron expression has no timezone field. The scheduler uses the server's configured timezone, which may be UTC, a local zone or a container default. Daylight-saving changes can make a task run twice, skip an hour or shift relative to local time. If exact local timing matters, confirm the server timezone and test around a DST boundary. For critical jobs, use a scheduler that exposes timezone settings explicitly.

Presets and the builder

The preset buttons fill in a known expression for convenience, but they may not update every builder control in the current page. Treat the expression panel as the source of truth. If you change a preset and then edit a time field, check the generated expression again before copying it. The page does not save schedules or deploy them to a server.

Where cron is used

Cron is common on Linux servers, in container images, in CI systems and in application schedulers. It can trigger backups, report generation, cache cleanup, email queues and sync jobs. The expression only describes when to run; it does not contain the command, the environment, the user or the retry policy. Those details live in the crontab or scheduler configuration.

Limits and edge cases

The tool supports standard five-field expressions. It does not support seconds, years, `@reboot`, `@daily` macros or vendor-specific extensions in the explainer. An expression can be syntactically valid but still never run, such as a date that does not exist in the selected month. The builder does not validate that the command is safe or that the job is idempotent. The page runs entirely in your browser.

Common problems

If the explanation looks wrong, check the field order and whether you used a six-field Quartz expression. If the next run is missing, the date may be impossible. If a job runs at the wrong local time, check the server timezone and DST. If a preset does not fill every field, edit the expression directly. If the page does not load, a CDN dependency may be blocked.

What not to do

Do not assume cron uses your laptop's timezone. Do not use `*` in every field for a job that should run once. Do not schedule overlapping long jobs without a lock. Do not put secrets directly in a crontab command. Do not rely on the English description alone for a complex schedule; verify the next runs and test the job. Do not use a five-field expression in a system that expects six fields.

Testing a schedule before deployment

Treat the generated expression as a draft. Add the job to a staging crontab or a scheduler test mode, set a short interval and confirm that it fires when expected. Log the start time, the end time and the exit code. Check what happens when the task runs longer than the interval, and add a lock if overlap would be harmful. The expression only says when to start; your job still needs error handling, retries and a way to alert someone when it fails.

Frequently Asked Questions