Cron Generator

How do the 5 fields work?

Cron works with five fields: minute (0-59), hour (0-23), day-of-month (1-31), month (1-12) and day-of-week (0-6, 0=Sun). Each one takes numbers, lists (1,2,3), ranges (1-5), steps (*/15) and * (any value).

In practice, 0 9 * * 1-5 fires at 9 a.m. on weekdays, while */15 * * * * runs every 15 minutes.

Start from the presets, then tweak by hand as needed.

Cron expressions in depth: syntax, variants, and real-world scheduling

A cron expression is a compact, time-based mini-language used to describe when a recurring job should run. Originally introduced in 7th Edition Unix in the mid-1970s, the format survived essentially unchanged for half a century and now ships inside Linux distributions, container orchestrators like Kubernetes, CI platforms like GitHub Actions, and serverless schedulers like AWS EventBridge and Vercel Cron. Despite the family resemblance, each platform reads the same five (or six, or seven) numbers a little differently — and getting one digit wrong is the difference between a backup that runs at 3 a.m. and one that runs every minute of the day.

This generator emits the classic Unix cron form. Below you will find a deep reference on field semantics, operators, special strings, dialect differences (Quartz, Spring, Kubernetes, GitHub Actions), worked examples, and the timezone/DST traps that catch even experienced engineers.

The five fields of standard Unix cron

A canonical crontab line packs five whitespace-separated fields, read left to right:

┌──────── minute        (0-59)
│ ┌────── hour          (0-23)
│ │ ┌──── day of month  (1-31)
│ │ │ ┌── month         (1-12 or JAN-DEC)
│ │ │ │ ┌ day of week   (0-7 or SUN-SAT; 0 and 7 = Sunday)
│ │ │ │ │
* * * * * command-to-run

The expression fires when every field matches the current wall clock — with one famous exception described later. Some schedulers add a sixth seconds field at the front, and Quartz adds a seventh year field at the end; the Linux and BSD daemons are minute-resolution only.

Wildcards, ranges, lists, and step values

• * — any legal value (every minute, every hour, etc.).
• a-b — inclusive range. 9-17 in the hour field means 9, 10, 11, 12, 13, 14, 15, 16, 17.
• a,b,c — discrete list. 0,15,30,45 matches the quarter hours.
• */n — step every n units. */5 in minutes runs at 0, 5, 10, … 55.
• a-b/n — stepped range. 0-23/2 in hours means every other hour starting at midnight.
• Month and day-of-week accept three-letter names: JAN-DEC, SUN-SAT. Names are case-insensitive but not combinable with ranges in some implementations.

Convenience strings: @yearly, @monthly, @daily, @hourly, @reboot

Vixie cron and most modern descendants accept named shortcuts that expand to a full five-field expression:

@yearly   (or @annually) → 0 0 1 1 *   midnight on January 1st
@monthly                  → 0 0 1 * *   midnight on the 1st
@weekly                   → 0 0 * * 0   midnight on Sunday
@daily    (or @midnight)  → 0 0 * * *   every day at midnight
@hourly                   → 0 * * * *   at minute 0 of every hour
@reboot                   → on cron daemon startup (no time fields)

Note: @reboot is not supported by Kubernetes CronJob, GitHub Actions, or systemd timers — it is a property of the cron daemon itself.

Dialect differences: Quartz, Spring, Kubernetes, GitHub Actions

The biggest source of cron bugs is assuming all schedulers parse the same string the same way. Quick reference:

• Unix / Vixie cron: 5 fields, day-of-week 0-7 (Sunday is both 0 and 7), minute resolution, OR semantics between day-of-month and day-of-week.
• Quartz (Java): 6 or 7 fields — seconds at the front, optional year at the back. Day-of-week is 1-7 with Sunday = 1. Supports L (last), W (nearest weekday), # (nth occurrence), and ? (no specific value).
• Spring @Scheduled: 6 fields (seconds + standard 5). Sunday = 0 like Unix, not 1 like Quartz — a common porting pitfall.
• Kubernetes CronJob: standard 5 fields. Times are UTC unless you set .spec.timeZone (k8s 1.25+). CRON_TZ= prefixes are rejected at validation time.
• GitHub Actions: standard 5 fields, UTC only, no timezone parameter. The shortest interval is 5 minutes, and high-load periods can delay or skip runs.
• AWS EventBridge: 6 fields (year required), day-of-week 1-7 (Sunday = 1), uses ? like Quartz, and does not allow both day-of-month and day-of-week to be specified.

Worked examples

*/5 * * * *      every 5 minutes
0 * * * *        at minute 0 of every hour (top of the hour)
30 2 * * *       every day at 02:30
0 3 * * 1        every Monday at 03:00
0 0 1 * *        midnight on the 1st of every month
0 9-17 * * 1-5   every hour from 09:00 to 17:00, Mon-Fri
15 14 1 * *      14:15 on the 1st of each month
0 22 * * 1-5     every weekday at 22:00
0 0 */2 * *      midnight every other day
*/15 9-17 * * 1-5 every 15 min from 09:00-17:59, weekdays
0 0 1 1 *        once a year, January 1st at midnight
5 4 * * sun      every Sunday at 04:05

Common traps: OR semantics, timezones, and daylight saving

Day-of-month and day-of-week are OR-ed, not AND-ed. The expression 0 0 13 * 5 fires on the 13th of every month and on every Friday — not just Friday the 13th. To get true AND behavior, restrict one field in the expression and check the other inside your script, or use Quartz/AWS which interpret a literal value plus ? differently.

Timezone. Linux cron honours the system TZ; you can override per crontab with a CRON_TZ=America/Sao_Paulo line. Kubernetes uses UTC by default. GitHub Actions is UTC, full stop — if you want 09:00 in São Paulo (BRT, UTC-3), write 0 12 * * *.

Daylight saving. When the clock springs forward, the skipped hour's jobs are usually lost; when it falls back, the repeated hour's jobs may execute twice. Modern Vixie cron tries to avoid both, but the safest fix is to schedule outside the 01:00-04:00 DST window or run on UTC.

Body of the job. Cron runs commands with a minimal PATH and no interactive shell. Always use absolute paths to binaries and redirect stdout/stderr (>> /var/log/job.log 2>&1) so failures are debuggable.

Where to deploy a cron schedule

• crontab on a single Linux host — crontab -e per user.
• systemd timers — calendar-event syntax (not cron-compatible) but with better logging, dependency graphs, and persistence across reboots.
• Kubernetes CronJob — declarative YAML, with concurrency policy and retry budget.
• GitHub Actions on.schedule — CI-driven jobs, UTC only, minimum 5-minute granularity.
• Vercel Cron / Netlify Scheduled Functions — invoke an HTTPS endpoint from a managed scheduler.
• AWS EventBridge / GCP Cloud Scheduler — cloud-native triggers with retry and dead-letter queues.

FAQ

Can cron run jobs more often than once a minute? Standard Unix cron cannot. For sub-minute scheduling use Quartz, a systemd timer with OnUnitActiveSec=30s, or a small loop inside the script itself.

What is the difference between 0 and * in the minute field? 0 fires only at minute zero; * fires every minute. 0 * * * * is hourly; * * * * * is every minute (sixty times per hour).

Why did my job run twice? Common causes: DST fallback, two cron daemons (system + user) reading the same file, or a previous run that exceeded the interval and overlapped — set a lock with flock to prevent overlapping invocations.

Does @reboot guarantee my job runs on every boot? Only if the cron daemon starts after the conditions your script needs (network, mounts). For modern Linux, prefer a systemd unit with After=network-online.target.

Is there a way to test a cron expression before deploying? Yes — paste it into a validator like crontab.guru, or use this generator and inspect the next N execution times in your CI logs before promoting to production.