Cron Expression Builder

Build a cron schedule field by field, or paste an existing expression to find out what it actually does. Either way you get a plain-English description and the next five run times computed in your local timezone — so you can confirm the schedule before it goes anywhere near production.

Minute

Hour

Day of Month

Month

Day of Week

* * * * *

Every minute

Next 5 Runs

UTC

1Fri, Sep 4, 2026, 2:10 PM
2Fri, Sep 4, 2026, 2:11 PM
3Fri, Sep 4, 2026, 2:12 PM
4Fri, Sep 4, 2026, 2:13 PM
5Fri, Sep 4, 2026, 2:14 PM

How to Use Cron Expression Builder

1

Build or paste an expression

Use the Build tab's dropdowns to set each field — Every, Specific values, or an Interval — or switch to Explain and paste an existing expression.

2

Read the plain-English description

The tool translates the expression into a sentence like 'At 9:00 AM, only on Monday, Tuesday, Wednesday, Thursday, and Friday' so you can sanity-check the intent.

3

Verify the next runs and copy

Confirm the next five run times in your timezone look right, then click Copy Expression to use it in your crontab or CI config.

About Cron Expression Builder

How cron expressions work

A standard cron expression is five space-separated fields: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, Sunday first). Each field accepts a specific value, a * wildcard, comma lists like 1,15, ranges like 9-17, and step intervals like */5. Reading them takes practice — 0 9 * * 1-5 means 9:00 AM every weekday — and writing them from memory is where scheduling bugs are born. This tool works in both directions: build an expression visually, or decode one you've inherited.

The gotchas that break schedules

Cron has sharp edges. When both day-of-month and day-of-week are restricted, most cron daemons run the job when either matches — an OR, not an AND — which surprises nearly everyone. Day-of-week accepts both 0 and 7 for Sunday. And cron runs in the server's timezone, so a job scheduled for 9 AM UTC fires at 3 AM in Chicago. This tool implements standard OR semantics, accepts month and day names like JAN and MON, and shows upcoming runs in your local timezone so timezone math mistakes surface immediately.

Verify before you deploy

The most valuable feature of any cron tool is seeing concrete run times before the schedule is live. An expression can be syntactically valid but semantically wrong — */30 9 * * * runs twice an hour during the 9 AM hour only, not every 30 minutes all day. The next-five-runs preview computes actual dates and times from your expression, making that kind of misunderstanding obvious at a glance. Everything is calculated locally in your browser with nothing sent to a server, and the copy button gives you the exact string for your crontab, CI config, or scheduler.

Common uses for Cron Expression Builder

  • Write crontab entries for server maintenance scripts and backups
  • Decode inherited cron expressions in legacy systems before changing them
  • Schedule GitHub Actions, GitLab CI, or Jenkins jobs with confidence
  • Configure Kubernetes CronJobs and verify the schedule matches intent
  • Double-check that a schedule fires at the right local time before deploying

Frequently Asked Questions

What do the five fields in a cron expression mean?

In order: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, where 0 is Sunday). Each accepts specific values, * for every value, comma-separated lists, ranges like 1-5, and steps like */15. So 30 8 1 * * means 8:30 AM on the first day of every month.

What happens when I set both day-of-month and day-of-week?

Standard cron treats them as OR, not AND. The expression 0 9 15 * 1 runs at 9 AM on the 15th of the month AND on every Monday — both, not just Mondays that fall on the 15th. This is one of cron's most misunderstood behaviors, and this tool follows the standard so the run-time preview shows you exactly what a real cron daemon would do.

Are the next run times shown in my timezone?

Yes — run times are computed in your browser's local timezone, which is displayed above the list. Remember that your actual server may run cron in a different timezone, often UTC. If your server uses UTC, mentally shift the schedule accordingly, or set the CRON_TZ variable where your cron implementation supports it.

Does this support non-standard syntax like @daily or seconds?

This tool targets the standard five-field format that classic cron, most CI systems, and Kubernetes CronJobs use. Shortcuts like @daily and @reboot, and the six-field seconds variant used by Quartz and some Spring schedulers, aren't included — but @daily is simply 0 0 * * *, and any five-field expression you build here works in those systems too.

Why does my expression show no upcoming runs?

The date combination is likely impossible — for example, day 30 in month 2 never occurs, since February tops out at 29. The tool scans roughly five years ahead; if nothing matches in that window, it tells you rather than showing wrong dates. Double-check the day-of-month and month fields for combinations that can't exist.