Cron Expression Builder

The pager went off at 4:30 on a Friday morning in October. The on-call engineer stared at a cleanup job mid-execution and at its crontab line — `30 4 1,15 * 5` — with the specific dread of a person discovering their own signature on the problem. The job was supposed to run on the 1st and 15th of the month. It was October 30th. A Friday. What the expression actually meant, in the dialect of standard cron, was 'the 1st, the 15th, and every single Friday' — and that distinction had been quietly running a production job three extra days a month since summer.

That bug is not rare. It is the most common cron mistake in the world, and it survives because cron's day-of-week semantics are genuinely counterintuitive: restrict both day fields and the daemon treats them as alternatives, not conditions. Five fields, ten seconds to write, months of subtle damage. The only real defenses are knowing the semantics — or never writing the five fields by hand at all.

The Cron Expression Builder above is the second defense. It assembles expressions from visual fields and presets, translates whatever you build into plain English, and — the part that catches every bug in this story — computes the next run times from your device clock, so a schedule that fires on unexpected Fridays announces its intentions before it pages anyone. Build the expression here, verify the next runs, then paste it into crontab.

1. 1

   Start from a preset

   'Every 5 minutes,' 'weekdays at 9 a.m.,' 'first of the month at midnight,' 'Sunday 2:30 a.m.' — presets cover the majority of real schedules and give you a correct base to edit.

2. 2

   Dial in each field

   Five rows — minute, hour, day of month, month, day of week — each with values, ranges (1-5), steps (*/10), and lists (1,15). The builder writes the expression as you click; you never type a character unless you want to.

3. 3

   Read the human translation

   Every change updates a plain-English sentence: 'At 09:00 on every day-of-week from Monday through Friday.' If that sentence is not the schedule in your head, the expression is wrong — and now you know before production does.

4. 4

   Check the next run times

   The tool lists the next several execution times computed from your current clock. This is the Friday-bug detector: an accidental day-of-week match shows up in the next-7-days list in plain view.

5. 5

   Test the edge you're worried about

   Month-end? Leap years? The run-list spans far enough to show whether '0 0 L * *' style expressions and month boundaries behave the way you assume.

6. 6

   Copy into crontab

   Paste the finished expression into `crontab -e` on your machine, or into your scheduler's config — Kubernetes CronJob, GitHub Actions schedule, Cloud Scheduler all speak this dialect, with dialect caveats covered below.

A standard cron expression is five fields, separated by spaces, each constraining one axis of time:

Within a field, four syntaxes cover everything: a single value (9), a range (1-5), a list (1,15), and a step (*/10, or 10-50/5). Combinations are legal — `0 9 1-7 * 1` is 'nine o'clock on days 1–7 of the month that are Mondays,' which people use to approximate 'first Monday,' and which works only because of the semantics we are about to address. A field containing just * matches every value and, critically, marks that field as unrestricted.

Now the notorious part. Standard cron — the Vixie family that runs on Linux, macOS, and the BSDs — resolves the two day fields with this rule: if both day-of-month and day-of-week are restricted, the job fires when either matches. If either field is *, the restricted one governs alone. This is an OR where every human instinct expects an AND. The rationale is decades old and mildly regretted: the two day fields serve different scheduling styles, and the daemon refuses to guess which one you meant when you fill both. The consequence is the Friday-bug from the opening story, the 3 a.m. page, and a small permanent industry of cron-explainer pages — this builder's next-run list exists precisely because a plain-English translation alone doesn't always make the OR visible.

There are shorthand strings, too, worth having in your pocket: `@yearly`/`@annually` (0 0 1 1 *), `@monthly` (0 0 1 * *), `@weekly` (0 0 * * 0), `@daily`/`@midnight` (0 0 * * *), `@hourly` (0 * * * *), and `@reboot`, which runs once when the cron daemon starts rather than on any schedule. They expand to exactly the expressions shown, so you can use them interchangeably where crontab syntax is expected.

The builder's run-list is its most valuable feature, so here is what it looks like in practice. These examples are computed from a real reference point — Sunday, October 25, 2026, mid-afternoon — and every date below is correct for that anchor.

One production habit worth stealing from sysadmins with scar tissue: avoid scheduling everything at minute 0. Every cluster on earth has a dozen jobs at `0 * * * *`, and they thunder into contention on the hour, every hour. Spreading jobs across odd minutes — `7 */2 * * *`, `23 3 * * *` — costs nothing and quietly removes a whole class of load-spike mysteries. The builder's per-field dropdowns make that staggering a two-second decision instead of a mental arithmetic chore.

Beyond the OR rule, cron has a small set of documented-but-undiscovered behaviors. Each of these has cost somebody a night's sleep:

• The percent sign is a newline. In a crontab command, the first unescaped % starts the command's standard input and becomes a newline; every later % becomes another newline. `date +%F` truncates at the %; `date +\%F` works. Escape every % in cron commands and you will never meet this one.
• The environment is a desert. Cron jobs run with a minimal environment — a short PATH, no shell profile, often no locale you expect. Scripts that work perfectly in your interactive shell fail in cron because /usr/local/bin isn't on PATH. Absolute paths everywhere, or set PATH explicitly at the top of the crontab.
• Missed runs stay missed. Cron matches the current minute; it does not replay history. A machine asleep or powered off at the scheduled minute simply skips the job. anacron exists for this; systemd timers have Persistent= for it.
• Time zones bite twice. The daemon's TZ decides when '9 a.m.' happens — usually the server's local zone, configurable per-line in modern Vixie cron with CRON_TZ, and settable to UTC in containers where 'local' is a fiction. And DST transitions can double-fire or skip an hour for jobs landing in the 01:00–03:00 window.
• Sunday is 0 and 7, but Quartz disagrees. Port an expression to a Java system and 7 stops being Sunday — Quartz's day-of-week runs 1–7 with Sunday as 1. Any port between dialects deserves a fresh read-through of the next section.
• Names don't step. You can write JAN or MON in the month and weekday fields, but combine names with ranges or steps in most implementations and the parser will decline, sometimes unkindly.

Syntax tables teach fields; a real crontab teaches judgment. Below is the scheduled-jobs file from a small production server, cleaned of anything incriminating, with every line written the way it is for a reason. Read it as six small decisions rather than six strings.

# daily backup at 02:17 — off the hour, off the :00
17 2 * * * /usr/local/bin/backup-db.sh >> /var/log/backup.log 2>&1
# temp cleanup on the 1st at 04:33
33 4 1 * * /usr/local/bin/cleanup-temp.sh
# cache warm on weekday mornings at 09:07
7 9 * * 1-5 /usr/local/bin/warm-cache.sh
# invoice run on the 1st at midnight
0 0 1 * * /usr/local/bin/invoice-run.sh
# health probe every five minutes
*/5 * * * * /usr/local/bin/health-probe.sh
# month-start and mid-month report — the Friday bug, repaired
30 4 1,15 * * /usr/local/bin/report.sh

The probe line hides the one failure mode this file still has to defend against by hand: overlapping runs. A job scheduled every five minutes that takes seven minutes will find its second copy starting while the first is still running, and the two will race each other for the same resources every single invocation after that. Cron has no built-in guard, so the script takes one — the flock pattern wraps the work in a lock that fails fast when the previous run still holds it: `flock -n /tmp/probe.lock /usr/local/bin/health-probe.sh`. The -n flag means non-blocking: if the lock is taken, this run exits quietly instead of queueing a zombie. Database migrations and file syncs want the same treatment, whatever the scheduler.

One more boundary case this file sidesteps by not existing: day-of-month 31. A job written `0 0 31 * *` fires in the seven 31-day months and never in February, April, June, September, or November — a schedule that quietly loses five months a year. Standard cron has no last-day-of-month token (Quartz's L exists precisely for this), so the standard workaround runs on days 28 through 31 and lets the script itself check whether tomorrow is the 1st before doing anything. The builder's next-run list surfaces the gap immediately: ask it for a month of runs on the 31st pattern and watch February return nothing.

Who builds cron expressions? The honest answer is 'almost everyone who operates software,' sliced into a few distinct habits.

Sysadmins are the natives — they speak five-field cron fluently, and what they want from a builder is speed and the next-run list as a verification step, not education. Backend and platform developers meet cron through Kubernetes CronJobs, GitHub Actions schedules, and cloud schedulers, all of which accept standard five-field expressions — and all of which fail differently from a Linux crontab when day semantics or time zones are involved, which sends them searching. Data engineers schedule pipelines and dbt jobs and live in mortal fear of the double-run at midnight UTC boundaries. Java teams live on Quartz and must consciously translate between dialects — the comparison below is for them. And students and junior engineers encounter cron in the same place everyone always has: the week something must 'run automatically every night,' which is how a generation has met the OR rule since 1975. Demand for builders and explainers of cron has been continuous for as long as search engines have measured it; the tool category is about as evergreen as software gets.

The deepest difference is the one the opening story was about. Quartz resolves the two day fields with AND semantics — you can set both and it means both — and provides the `?` character to explicitly mark a field as unset. Standard cron's OR is the historical accident Quartz was designed to fix. So the same string means different things in the two dialects whenever both day fields are restricted, and nothing else about the expression warns you. This builder produces standard five-field cron; if your destination is Quartz, translate deliberately, and if your team runs both dialects in the same stack, write the dialect on the wall next to the schedule.

Expression assembly, the plain-English translation, and the next-run computation all happen in your browser. There is no server round-trip for any of it, which is why the translation updates as you click rather than after a spinner.

Next-run computation is worth a sentence on method, since its correctness is the whole point: the tool evaluates your expression against the minute grid the same way a daemon would, starting from your device clock, and lists the matches it finds. That makes it an honest simulation of standard Vixie semantics — including the OR rule — rather than a dictionary of common patterns. The privacy consequence is the same as every tool in this cluster: schedules are internal infrastructure information, and a builder that ships them to a server for evaluation is creating a record of your systems' timing for no architectural reason. This one keeps your schedules exactly where they started.

The schedule-adjacent toolkit on this site is deliberately deep. When you already have an expression and need it decoded rather than built, the Cron Expression Explainer is the reverse operation — paste the five fields, get the semantics and next runs. For the other repo-infrastructure files that pair with automation, the .gitignore Generator and its neighbor in your first commit are covered elsewhere on this page's cluster. And when the scheduled job's failure mode is an HTTP problem — a webhook, a health check, a 429 that started everything — the HTTP Status Code Lookup decodes what came back.

Build here, explain there, and debug the response codes when the run happens. That trio covers most of the scheduled-job lifecycle.

Cron's semantics are documented at the source. These four references define everything this builder implements: