About Cron Expression Generator

A cron generator builds a standard 5-field crontab expression from plain choices, so you can schedule a job without memorizing the field order.

It covers the classic format used by Linux cron, Kubernetes CronJob, and most CI schedulers: minute, hour, day of month, month, day of week. There is no seconds field, so Quartz style 6-field or 7-field expressions are out of scope.

How to use the Cron Expression Generator

Start from a preset such as every 5 minutes, every hour, daily at midnight, weekdays at 09:00, or monthly on the 1st. The preset fills the field controls below so you can keep tuning it.
Adjust any field with one of five modes: Every for a plain asterisk, Every N for a step like */15, Range for a span like 9-17, List for values like 1,15,30, and Exact for a single number.
Read the expression as it updates live, then copy it into your crontab, CI config, or CronJob manifest.
Check the next 6 run times shown below it. That preview is the fastest way to catch a value set on the wrong field.

When you would use it

Schedule a nightly database backup that must finish before business hours start.
Rotate or archive logs on a fixed weekly or monthly cadence.
Warm a cache or rebuild a search index before a daily traffic peak.
Send a report every Monday morning, or on the first day of each month for billing.
Trigger a nightly CI build and a regular certificate renewal check.

Cron syntax rules that cause most mistakes

The five fields are minute, hour, day of month, month, and day of week, in that order. Most incorrect schedules come from a few semantics that are easy to misread.

When day of month and day of week are both set to something other than an asterisk, cron combines them with OR, not AND. So 0 0 13 * FRI means the 13th of every month or every Friday, not only a Friday the 13th.
A step like */15 starts at 0 and repeats every 15 units, giving 0, 15, 30, 45. A step written as 5/15 starts at 5 and runs to the maximum, giving 5, 20, 35, 50.
In the day of week field both 0 and 7 mean Sunday, so the same schedule can be written two ways.
Month and day of week accept three-letter names such as JAN through DEC and MON through SUN.
Cron runs in the local time zone of the machine holding the schedule, so confirm that time zone before deploying. Daylight saving transitions can skip or repeat an hourly slot.

Cron generator FAQ

Does this tool support a seconds field?: No. It produces the standard 5-field crontab format only. Quartz and some Java schedulers use 6 or 7 fields with seconds and an optional year, which are not generated here.
Why does my day of month plus day of week schedule fire more often than expected?: Because cron treats those two fields as OR when neither is an asterisk. For a strict AND condition, schedule the broader cron and add a date check inside the job.
Is it safe to run a job every minute?: Only if a single run finishes well under a minute. Otherwise runs overlap and pile up, so add a lock file or a single-instance guard, or use a longer interval.
Which time zone do the next run times use?: The preview uses your browser time zone. The machine that executes the schedule uses its own, so verify they match before relying on an exact hour.
Is my schedule uploaded anywhere?: No. Every expression on wetool.site is built and previewed entirely in your browser, and nothing you enter is sent to a server.

Cron generator vs cron parser

The cron parser on this site solves the opposite problem: you already have an expression and want to know what it means and when it fires next. This generator goes the other direction, turning a schedule you can describe in words into correct syntax. The two are complementary, so after generating an expression you can paste it into the parser as an independent second check.

Checks before you deploy a schedule

An expression that looks right can still fire at the wrong moment on a real server. A short review catches most of it.

Compare the next 6 run times against what you intended, especially the first one, which exposes off-by-one field errors immediately.
Confirm the time zone of the executing machine or container, and prefer UTC for systems that span regions.
Spread heavy jobs across different minutes instead of stacking everything at minute 0.
Decide what should happen if a run is missed while the host is down, since standard cron does not catch up on skipped runs.