Generate CRON Expression Online

How to Generate a Cron Expression Online

1. Pick a Preset or Start Blank: Click "Every minute," "Hourly," "Daily at midnight," "Weekly on Monday," or "Monthly on 1st" to load a starter pattern, or leave the builder at its defaults and configure each field below.
2. Configure the Five Fields: Set Minute (0-59), Hour (0-23), Day (Month) (1-31), Month (1-12 or JAN-DEC), and Day (Week) (0-6 or SUN-SAT) using * for any value, a comma list (1,15), a range (MON-FRI), or a step (*/15).
3. Read the Description and Next 5 Executions: The plain-English Description updates as you type ("At 09:00 on every day-of-week from Monday through Friday"), and the Next 5 Executions panel lists upcoming run times so you can sanity-check the pattern before deploying it.
4. Copy the Cron Expression: Click the Copy button next to the Cron Expression field and paste it into your crontab -e, GitHub Actions schedule: block, Kubernetes CronJob manifest, or scheduler config. Everything runs client-side — no jobs, expressions, or hostnames leave your browser.

Why Use a Cron Generator?

Cron's five-field syntax is dense by design: 0 */6 * * 1-5 packs "every six hours, weekdays only" into eleven characters. That density is great for editing a crontab over SSH and terrible for getting it right the first time. The two classic traps — swapping the day-of-month and day-of-week fields, and assuming both restricted day fields combine with AND when standard cron actually combines them with OR — are both invisible until the job runs at the wrong time. A visual builder with a live English description and a next-run preview catches these before they hit production.

• Linux cron jobs and system maintenance — Backups, log rotation, certbot renew, package updates, and disk health probes all run on cron schedules. Verify with the Next 5 Executions panel before saving your crontab.
• GitHub Actions, GitLab CI, and CircleCI schedules — The schedule: cron: key in workflow YAML accepts standard five-field cron (UTC). GitHub specifically warns that scheduled workflows can be delayed during high load, so spread jobs out instead of stacking them on the hour.
• Kubernetes CronJob and Argo Workflows — Both use standard five-field cron in the schedule field. The Kubernetes controller treats the cluster timezone as UTC unless you set spec.timeZone (stable since Kubernetes 1.27).
• Cloud schedulers — AWS EventBridge, GCP Cloud Scheduler, Azure — EventBridge requires the six-field flavor with a year field and ? in either day-of-month or day-of-week. GCP Cloud Scheduler uses standard five-field cron with an explicit time_zone parameter. Use the right dialect for the right service.
• Application schedulers — Spring @Scheduled, Quartz, node-cron — Quartz adds a seconds field at the front (six required fields) and a year field at the end (seven max). Spring's @Scheduled(cron=) follows Quartz semantics with the same ? wildcard rules.
• Jenkins build triggers — Jenkins inherits Quartz but adds the H (hash) macro for load spreading. Need a UUID for a one-off job ID, or a quick regex check on your trigger string? Pair this tool with those.

Cron Field Reference (Standard 5-Field Unix)

Position	Field	Allowed Values	Aliases	Notes
1	Minute	0-59	—	*/15 = every 15 min
2	Hour	0-23	—	0 = midnight, 23 = 11 PM
3	Day of Month	1-31	—	Skipped in months that lack the day
4	Month	1-12	JAN-DEC	Case-insensitive aliases
5	Day of Week	0-6	SUN-SAT	Both 0 and 7 = Sunday in Vixie/GNU cron

Special Characters and Cron Dialect Comparison

Symbol	Meaning	Unix / Vixie cron	Quartz / Spring	Jenkins	AWS EventBridge
*	Any value	Yes	Yes	Yes	Yes
,	List (1,15,30)	Yes	Yes	Yes	Yes
-	Range (1-5)	Yes	Yes	Yes	Yes
/	Step (*/15)	Yes (modern)	Yes	Yes	Yes
?	"No specific value" — DOM or DOW	No	Yes	Yes	Required in one of DOM/DOW
L	Last day of month/week	No	Yes	No	Yes
W	Nearest weekday to date	No	Yes	No	Yes
#	Nth weekday of month (6#3 = 3rd Fri)	No	Yes	No	Yes
H	Hash — stable random within range	No	No	Yes	No
Fields	Required count	5	6 (+1 optional year, 7 max)	5	6 (year required)
DOW numbering	Sunday =	0 or 7	1 (SUN) - 7 (SAT)	0-7	1 (SUN) - 7 (SAT)

Frequently Asked Questions

What is the difference between Unix cron, Quartz cron, and Jenkins cron?

Three dialects, three field counts. Standard Unix cron (Vixie, GNU, BusyBox, BSD) uses five fields: minute, hour, day-of-month, month, day-of-week. Quartz adds a seconds field at the start (six required) and an optional year field at the end (seven max), and uses 1-7 for day-of-week where Sunday is 1. Jenkins is "Quartz-flavored with quirks": still five fields like Unix cron, but it adds the H hash macro to spread jobs across the cluster. Pasting a Unix expression directly into AWS EventBridge or Quartz will be rejected — they expect the ? wildcard in either day-of-month or day-of-week, and they need the year/seconds field that Unix doesn't have.

If I restrict both day-of-month and day-of-week, do they AND or OR?

Standard Unix/Vixie cron uses OR logic when both fields are restricted (neither is * or */something). The job fires when either condition matches. So 0 9 15 * 1 runs at 9:00 on the 15th of every month AND every Monday — not just Mondays that fall on the 15th. This is the single most common cron footgun. Quartz and AWS EventBridge sidestep the problem entirely by requiring ? in one of the two fields. systemd timers' OnCalendar= syntax also uses AND semantics. If you need "the 15th, only if it's a Monday," your cleanest option is a [ "$(date +\%u-\%d)" = "1-15" ] && command guard in the cron line itself.

Why does Jenkins use H in its cron and what does it do?

H ("hash") is Jenkins' way of preventing the thundering-herd problem when hundreds of jobs all schedule themselves with 0 0 * * *. Instead of every job firing at midnight, H is replaced by a value that's hashed from the job name — stable for that job, but spread across the allowed range. H * * * * runs every job once an hour at a job-specific minute; H H * * * runs daily at a job-specific hour-and-minute combo. Critically, it's deterministic from the job name, not random, so the same job always runs at the same offset — but two different jobs land in different slots. Use it on anything Jenkins runs at fixed intervals and you'll see CI worker load flatten out immediately.

What timezone do cron expressions use?

The expression itself carries no timezone — interpretation is the scheduler's job. Linux cron and crond use the system timezone, which is usually UTC on cloud VMs and the local zone on workstations; some distros (Debian, Ubuntu) honor a CRON_TZ=America/New_York line at the top of the crontab. Kubernetes CronJob defaults to UTC but accepts spec.timeZone as of v1.27. GCP Cloud Scheduler and AWS EventBridge Scheduler require an explicit timezone. The dangerous edge cases are DST transitions: a 30 2 * * * job on the "spring forward" night never fires (2:30 AM doesn't exist) and fires twice on "fall back." When that matters, schedule outside the 1-3 AM window or use a scheduler with explicit DST handling.

Cron vs systemd timers — when should I use which?

Cron is the right tool when you want a one-line, portable schedule (0 3 * * * /usr/local/bin/backup.sh) that runs everywhere the same way. systemd timers are better when you need: dependency on other units, missed-run catch-up (Persistent=true runs the job after boot if the trigger time was missed during downtime), randomized delay (RandomizedDelaySec=), accounting integration with systemd-cgls, or per-user resource limits. The cost is verbosity — every job needs both a .service and a .timer unit. Rule of thumb: stick with cron for sysadmin one-liners, switch to systemd timers when you're already managing the workload as a systemd service.

How many fields does a cron expression have — 5, 6, or 7?

Depends on the dialect. 5 fields = standard Unix / Vixie / GNU cron / Linux crontab / Kubernetes CronJob / GitHub Actions / GCP Cloud Scheduler / Jenkins (without seconds): min hour dom month dow. 6 fields with seconds at front = Quartz / Spring / most Java schedulers: sec min hour dom month dow. 6 fields with year at end = AWS EventBridge: min hour dom month dow year. 7 fields = Quartz max with both seconds and year: sec min hour dom month dow year. The generator above outputs the standard 5-field Unix format — for Quartz or EventBridge, prepend 0 (seconds) or append * (year) and replace * in DOM or DOW with ?.

Does AWS EventBridge accept standard Unix cron expressions?

No. EventBridge wraps the schedule in cron(...) and requires the six-field format cron(minutes hours day-of-month month day-of-week year) where year is mandatory (use * for every year). It also requires ? in exactly one of day-of-month or day-of-week — you cannot specify both, and you cannot leave both as *. Day-of-week is 1-7 (Sunday=1), not 0-6 like Unix. So 0 9 * * 1-5 from a Linux crontab becomes cron(0 9 ? * MON-FRI *) in EventBridge. EventBridge Scheduler (the newer service) accepts a timezone field; the legacy CloudWatch Events scheduler is UTC-only.

Why doesn't my */7 step value land where I expected at the top of the hour?

Step values are calculated from the start of the field's range, not from the current time. */7 in the minute field fires at 0, 7, 14, 21, 28, 35, 42, 49, 56 — then resets to 0 at the top of the next hour, giving an irregular 4-minute gap between 56 and the next 0. Same trap with */13 in hours (0, 13 then reset). If you need a true "every N units" cadence that doesn't reset on field boundaries, use a scheduler with interval-based triggers (systemd OnUnitActiveSec=, GCP Cloud Scheduler's rate(...), or AWS EventBridge rate(7 minutes)) instead of cron.

Can I validate or reverse-engineer an existing cron expression?

Yes. Paste any 5-, 6-, or 7-field expression into the Cron Expression field and the builder reflects it back into the dropdowns, generates the plain-English Description, and lists the Next 5 Executions. This is the fastest way to debug an inherited crontab where a line like 0 0 1-7 * 1 means "first Monday of the month" — except it doesn't, because of the OR-logic trap (see above). For other config formats, pair with YAML Validator, JSON Formatter, and XML Validator when you're prepping the surrounding workflow file. For one-shot timestamp arithmetic, use Date to Timestamp.