Cron Expression Builder

What this tool does

This tool builds a cron expression from five separate fields — minute, hour, day of month, month and day of week — instead of asking you to write the raw five-field string directly. As you fill in each field, the assembled expression, its plain-English meaning and its next few run times update together.

When you need it

• Building a schedule from scratch when you know when you want something to run but don't want to hand-assemble the cron syntax from memory.
• Teaching someone the structure of a cron expression by letting them change one field at a time and see the effect.
• Constructing a schedule for a system you don't want to get wrong on the first try — a production deploy job, a billing run, a data pipeline trigger — by checking the plain-English explanation and preview run times before committing to it.
• Working backward from "every 15 minutes" or "the first of every month" to the correct field syntax without memorizing step-value or range notation.

What you can type into each field

Each field accepts standard cron field syntax: * for "every value" in that field, a specific number, a comma-separated list like 1,15, a range like 1-5, or a step value like */15. The day-of-month, month and day-of-week fields default to *, since most everyday schedules only constrain the minute and hour. Day-of-week uses 0–6 where 0 is Sunday; 7 is also accepted as Sunday, as in Vixie cron.

Reading the result

The assembled expression is shown exactly as you'd paste it into a crontab or a CI configuration file. Below it, the plain-English explanation restates what the expression means in words, which is the fastest way to catch a mistake — if you meant "every weekday at 9 AM" and the explanation reads "every day at 9 AM," you've likely left the day-of-week field as * instead of setting 1-5. The next three run times, computed from a starting date field, show concretely when the schedule will actually fire.

Validation as you build

If a field value is out of range for its position — a minute above 59, an hour above 23, a day-of-week value above 7 — the tool reports the exact problem instead of silently building an expression that would fail when a real scheduler tries to parse it. This catches the mistake at build time rather than when a job unexpectedly doesn't run in production.

Once you have an expression

If you're building specifically for a GitHub Actions workflow, use the GitHub Actions cron generator instead, which wraps the same field-by-field builder in a ready-to-paste on: schedule: YAML block and flags schedules more frequent than GitHub's 5-minute minimum. If you already have an expression from somewhere else and just want it explained, the cron explainer takes that expression directly.