How to use this cron builder
The fastest path: click a preset chip and you're done. For anything custom, type into the big expression field or edit the five field boxes below it — they're two views of the same thing, kept in sync both ways, so use whichever feels natural. Quick-set buttons under each field drop in the values people actually use most.
As you type, the tool validates every field (with the exact problem highlighted in red), translates the schedule into plain English, and computes the next five times it will fire on your machine's clock. When it reads the way you intended, hit Copy and paste it into your crontab, GitHub Actions workflow, or Kubernetes CronJob.
What is cron, and why is it everywhere?
Cron is Unix's job scheduler — a daemon that wakes up every minute, checks a table of schedules (the crontab), and runs whatever is due. It shipped from Bell Labs in 1975, and half a century later it is still quietly running the world's nightly backups, certificate renewals, and report emails.
The syntax survived because it's remarkably compact: five tiny fields
describe almost any recurring schedule, it greps well in a config
file, and once you know it you can read a schedule at a glance. The
problem is the learning curve — */15 9-17 * * 1-5 looks
like line noise until the pattern clicks. That's the exact gap this
tool fills.
And it's not just Linux anymore. You'll meet cron syntax in
GitHub Actions schedule blocks,
GitLab CI pipeline schedules, Kubernetes
CronJobs, Laravel's scheduler,
node-cron, AWS EventBridge rules, and GCP Cloud
Scheduler. Learn the five fields once and you can configure all of
them. (One caveat: some platforms bolt on a sixth seconds
field — this builder targets the standard five-field format that
nearly everything accepts.)
Anatomy of a cron expression
Five fields, one space between each, in this fixed order:
# ┌───────────── minute (0–59) # │ ┌─────────── hour (0–23) # │ │ ┌───────── day of month (1–31) # │ │ │ ┌─────── month (1–12, or JAN–DEC) # │ │ │ │ ┌───── day of week (0–6, SUN–SAT — 7 also means SUN) # │ │ │ │ │ */15 9-17 * * 1-5 # → every 15 minutes, between 09:00 and 17:59, Monday through Friday
The special characters
*— any value. "Every" of that field.,— a list:0,30means at minute 0 and minute 30.-— a range:9-17means 9 through 17 inclusive./— a step:*/15means every 15th value starting from the field's minimum. Combinable with ranges:10-40/10hits 10, 20, 30, 40.- Names —
JAN–DECandSUN–SATwork in most crons (case-insensitive), including in ranges likeMON-FRI. Not guaranteed on minimal systems, so numbers are the safe bet.
The @ macros
Vixie cron added readable shortcuts: @hourly,
@daily (same as @midnight),
@weekly, @monthly, @yearly
(same as @annually), and @reboot. Handy in
a crontab — but they don't work everywhere (GitHub Actions, for
instance, wants the numeric form), which is why this tool's presets
give you both.
Schedules people actually run
- Nightly backups —
0 2 * * *, 2am local, when nobody's touching the database. - Certificate renewal checks — Let's Encrypt's certbot suggests running twice a day so renewals never slip.
- Weekday standup nudges —
0 9 * * 1-5pings the channel at 9am, Monday to Friday. - Log rotation and cleanup — weekly jobs that compress old logs and prune expired sessions.
- Monday-morning reports —
0 7 * * 1emails the weekly summary before anyone's coffee is done. - Cache warming — rebuild caches at
30 5 * * *, fifteen minutes before the first traffic spike.
Classic cron pitfalls (the ones that page people at 3am)
- The day-of-month / day-of-week OR rule. If both fields are restricted, cron runs the job when either matches.
0 0 1 * 1fires on the 1st and every Monday — the single most common cron bug. Want AND? Check the date inside your script. - Timezones don't exist in cron. Schedules run in the server's local time, period. "2am" means 2am server-time — if the box is UTC, that's what you get. Set
TZdeliberately, and remember DST can skip a run (2:30am doesn't exist on spring-forward) or double it. - Sunday has two spellings. Both
0and7mean Sunday in the weekday field. Pick one for your team and stick to it. */ncounts from the field's floor.*/15in the minute field means :00, :15, :30, :45 — not "every 15 minutes from whenever you installed it."- Percent signs bite in crontabs. In a crontab file,
%means "newline" and everything after it is fed to the command's stdin. Escape it as\%or your date format strings will mysteriously truncate. - Names aren't POSIX.
JANandMONare Vixie cron extensions. Rock-solid on Linux servers, occasionally rejected by minimal schedulers — numbers always work.
Frequently asked questions
What's the difference between * and */1?
Nothing in practice — both match every value of the field. */1 is just the step syntax made explicit. Most people write * because it's shorter and clearer.
Why does my job run on the 1st of the month AND every Monday?
That's cron's famous OR rule: when both the day-of-month and day-of-week fields are restricted (neither is *), the job runs when either matches. If you want AND behavior, restructure — for example, check the date inside the script itself.
Are month and weekday names case-sensitive?
No — JAN, jan, and Jan are all fine in implementations that support names (like Vixie cron). But names aren't part of the POSIX standard, so some minimal crons only accept numbers. When in doubt, use numbers.
Does cron understand timezones?
Classic cron has no timezone field — schedules run in the server's local time. If your servers are UTC, your "2am backup" is 2am UTC. Some modern schedulers (systemd timers, cloud schedulers, several CI systems) let you set a timezone explicitly.
What does 0 0 1 1 * mean?
At 00:00 on the 1st of January — once a year, on New Year's Day. Minute 0, hour 0, day 1, month 1, any weekday.
Where can I use the expressions I build here?
Anywhere standard cron syntax is accepted: crontab -e on Linux/macOS, GitHub Actions schedule blocks, GitLab CI, Kubernetes CronJobs, Laravel's scheduler, node-cron, and most cloud schedulers. A few platforms add a sixth (seconds) field — check their docs.