Cron Expression Generator

build and explain cron schedule expressions with a visual builder

By Bikram NathLast updated May 19, 2026

Translates a five-field cron expression into plain English and assembles one from a visual picker. A common use is verifying a GitHub Actions schedule: type `0 9 * * 1-5` and confirm it means 'At 09:00, Monday through Friday.' Unlike a plain syntax reference, the builder lets you click individual minute or weekday values and see the expression update live.

Try it now — free, instant, no signup

What is Cron Expression Generator?

The tool accepts a standard five-field Unix cron expression, covering minute, hour, day-of-month, month, and day-of-week, and renders a sentence describing when the schedule fires. You can either type an expression directly or use the field pickers to select individual values, ranges, or step intervals, then read the human description to confirm the schedule matches intent.

crontab.guru handles the same translation use case and is the default for decoding a single expression from a Stack Overflow answer. Reach for this builder instead when constructing an expression from scratch, iterating through several variants, or when you need a visual reminder that month fields are 1-indexed while weekday fields start at 0 in most implementations.

The most commonly misunderstood behavior in standard Vixie cron: when you specify both day-of-month and day-of-week as non-wildcard values, most Unix cron daemons treat them as OR, not AND. A schedule like `15 2 1 * 5` runs on the first of every month AND on every Friday, not only on Fridays that fall on the first. AWS EventBridge sidesteps this with a mandatory `?` placeholder in whichever day field is unused.

When to use Cron Expression Generator

✓Verify a GitHub Actions `on.schedule` cron before pushing it by pasting the expression and reading the plain-English confirmation.

→Construct a Kubernetes CronJob schedule that runs every 15 minutes during business hours without memorizing field-position order.

⚡Debug an existing cron job that fires at unexpected times by entering the expression and checking whether step syntax parses as intended.

Frequently Asked Questions

Why does my job fire on every Friday AND the first of the month when I only wanted Fridays that fall on the first?

Standard Vixie cron, used by Linux cron, most CI platforms, and Kubernetes CronJobs, applies OR logic when both day-of-month and day-of-week are non-wildcards. A schedule like `0 9 1 * 5` runs at 09:00 on the first of every month and at 09:00 on every Friday, making it fire far more often than intended. To restrict a job to only a specific weekday-of-month combination, add a shell-level date check inside the job script itself, since five-field cron syntax has no AND operator for these two fields.

Does the generator support the six-field format used by Quartz Scheduler or AWS EventBridge?

The builder targets the standard five-field Unix cron format: `minute hour day-of-month month day-of-week`. Quartz Scheduler uses a six-field format that prepends a seconds field, and AWS EventBridge uses a six-field format as well, additionally requiring `?` instead of `*` in whichever of the two day fields is unused. Expressions generated here will not validate directly in Quartz or EventBridge contexts without modification. For EventBridge specifically, replace one `*` day field with `?` before using the output.

What is the difference between `*/5` and `0/5` in the minute field?

In the POSIX five-field cron specification, `*/5` in the minute field means every fifth minute starting from 0, equivalent to listing `0,5,10,15,20,25,30,35,40,45,50,55`. The notation `0/5` is a Quartz Scheduler extension that carries the same meaning in that context, but standard Unix cron daemons either reject it or interpret it differently. If you are writing a cron expression for Linux crond, macOS cron, or GitHub Actions, stick to `*/5` to avoid undefined behavior.

Can I use this to write a cron expression that runs on the last day of every month?

Five-field Unix cron syntax has no built-in shorthand for the last day of a month. The `L` character that means last-day is a Quartz Scheduler extension and is not recognized by Linux crond, Kubernetes CronJobs, or GitHub Actions. The standard workaround is to schedule the job on the 28th through 31st and include a guard in the script: `[ $(date -d tomorrow +%d) -eq 01 ] || exit 0`. This lets the job proceed only when tomorrow is the first, meaning today is the last day of the month.

Why does Sunday appear as both 0 and 7 in cron expressions I find online?

POSIX explicitly allows both 0 and 7 to represent Sunday in the weekday field, and most modern implementations including Vixie cron, systemd timers, and GitHub Actions honor both values. The duplication is a historical artifact: early Unix systems used 0, and some administrators used 7 intuitively as the seventh day of the week. Mixing them in a range like `0-7` with step notation can produce surprising results in stricter parsers, so pick one convention per expression. The value 0 is the safer choice for cross-platform compatibility.

Related Tools

Time

Unix Timestamp Converter

convert between Unix timestamps and human-readable dates

Time

Timezone Converter

convert times between any two time zones instantly

Time

Date Duration Calculator

calculate the duration between two dates or add/subtract time

Regex

Regex Tester

test and debug regular expressions with real-time matching