How to Build Cron Expressions

Cron expressions are the standard way to define recurring schedules in Linux, cloud platforms, CI/CD pipelines, and task schedulers. The syntax is compact but not intuitive, building a visual cron generator shows you exactly when your job will run, catches common errors before deployment, and removes the guesswork from the most error-prone part of automation. Once you understand the five fields, the special characters, and the most common pitfalls, you can specify any recurring schedule with confidence.

A short history of cron

The first cron came from Brian Kernighan in Version 7 Unix, around 1979. It re-read its configuration every minute and ran whatever was due. Paul Vixie rewrote it in 1987 into what is now called Vixie cron, which is the version most Linux distributions still ship. Vixie cron added per-user crontabs, environment variables, the @reboot keyword, and several quality-of-life features that made the format usable for non-administrators.

The 5-field syntax has barely changed in over forty years. Amazon EventBridge, Google Cloud Scheduler, Kubernetes CronJob, GitHub Actions, GitLab CI, Jenkins, Airflow, n8n, and dozens of other systems all consume the same compact format with only minor extensions. That stability is the reason cron is worth learning once and then never re-learning. The skill transfers everywhere automation runs on a clock.

Cron syntax

A standard cron expression has 5 fields, separated by spaces. Each field controls one slice of time, and a job runs whenever every field matches the current moment.

┌───────────── minute (0-59)
│ ┌───────────── hour (0-23)
│ │ ┌───────────── day of month (1-31)
│ │ │ ┌───────────── month (1-12, or JAN-DEC)
│ │ │ │ ┌───────────── day of week (0-6, Sun=0, or SUN-SAT)
│ │ │ │ │
* * * * *

The fields are ANDed together for hour, minute, and month, but day-of-month and day-of-week are ORed in Vixie cron. That means 0 12 1 * 1 fires on both the 1st of every month AND every Monday at noon, not only on Mondays that happen to be the 1st. This trap catches almost everyone the first time.

Common cron schedules

The patterns you will reach for most often:

Many systems also accept shorthand aliases that expand to the equivalent 5-field expression: @yearly, @monthly, @weekly, @daily, @hourly, and @reboot. They are concise but not universal, so check your platform before relying on them.

How to build a cron expression

1. Pick the granularity: do you need every minute, every hour, once a day, once a week, or once a month? Start at the coarsest setting that meets your need.
2. Use the visual controls: select minute, hour, day, month, and weekday values from the dropdowns. Or start with a preset like "every hour" or "daily at midnight" and adjust.
3. Preview the next run times: the generator shows the next 5 execution times, which lets you confirm the schedule fires when you expect.
4. Sanity-check the timezone: the preview should match the timezone of the server or scheduler that will run the job, not your local time.
5. Copy the expression and paste it into your crontab, GitHub Actions YAML, AWS EventBridge rule, or whichever scheduler you use.
6. Test with a short interval first before committing the final schedule. A quick */5 * * * * proves the job fires; once you see two or three runs land, swap in the real expression.

Special characters and operators

Cron supports a small but powerful set of operators inside any field.

Vanilla Vixie cron only supports the first five rows. The advanced operators (L, W, #, ?) come from Quartz, the Java scheduling library, and were adopted by AWS EventBridge and a few other cloud schedulers. They are not portable, so do not mix them with code that has to run on a generic Linux box.

Cron on different platforms

Cron is a family of related syntaxes, not a single standard. Knowing which dialect your scheduler speaks saves hours of debugging.

If you write a schedule that has to run on more than one platform, stick to the conservative 5-field subset that every system understands. Reach for L, W, or # only when you know the destination supports them.

Common pitfalls

• Day-of-month and day-of-week are ORed, an expression like 0 9 15 * 1 fires every Monday AND on the 15th of every month, not only on the 15th when it falls on a Monday. To intersect, you typically need an outer wrapper or a different scheduler.
• Timezone confusion, server crontabs almost always run in UTC. If you want 9 AM Eastern time, that is 0 14 * * * UTC in winter but 0 13 * * * UTC in summer because of daylight saving. Use a scheduler that supports timezone hints, or normalize everything to UTC.
• Daylight saving transitions, jobs scheduled at 02:30 local time may run twice when clocks fall back and not at all when they spring forward. Schedule sensitive jobs outside the 01:00-03:00 window or use UTC.
• The Vixie MAILTO trap, if your job prints anything to stdout, Vixie cron emails the output to the user that owns the crontab. On servers without a mail relay this fills /var/spool/mail quickly. Redirect output to a log file with >>/var/log/myjob.log 2>&1.
• Environment is not your login shell, cron runs with a stripped environment: no PATH from your .bashrc, no virtualenv, no nvm. Set the variables you need at the top of the crontab or call your script with an absolute path.
• Percent signs need escaping, an unescaped % in a Vixie crontab is interpreted as a newline character in the command. Always escape it as \% if your command needs a literal percent sign, for example in a date +"%Y-%m-%d" invocation.
• Long-running jobs overlap, cron does not skip a run because the previous one is still going. If your job can take longer than the interval, wrap it in a lock file (flock, setlock) or use a job runner that handles concurrency.
• Overflow at 59 minutes, */40 * * * * does not fire every 40 minutes. It fires at minute 0 and minute 40 of every hour because step values wrap around the field's bounds. For true 40-minute intervals you need a richer scheduler.
• Forgetting 0 in the minute field, * 9 * * * runs every minute from 09:00 through 09:59, not once at 09:00. The minute field needs an explicit value if you want a single firing per hour.
• Cron is unreliable on laptops, anacron exists for that reason. Vixie cron does not catch up on missed runs after a sleep, so a daily backup scheduled at 03:00 will not run if the laptop was closed at that hour. Use anacron, systemd timers with Persistent=true, or a launchd plist on macOS.

Alternatives to cron

For some workloads cron's coarse minute resolution and lack of bookkeeping start to hurt. The most common upgrades:

Cron remains the right answer for the vast majority of one-shot recurring jobs. The other tools shine when you need state, retries, dependencies, or coordination across machines.

Privacy and the cron generator

The cron expression generator runs entirely in your browser. The schedule you build, the preview of next run times, and the copied expression never touch our servers. There is no log of which expressions were generated, no telemetry on which presets are popular, and no way for anyone to reconstruct what schedule you were working on. Cron expressions are not personal data on their face, but the schedule of a job (a nightly database export, a weekly billing run, a hourly sync to a partner) can reveal a lot about how a business operates. Keeping that information client-side avoids accidentally leaking infrastructure patterns to a third party. For a task as routine as picking a schedule, the privacy default should match the sensitivity of what those schedules represent.