Cron Expression Generator Online

How to Build a Cron Expression

1. 1Click a preset to start from a common schedule, or set each field manually.
2. 2Adjust the five fields: Minute, Hour, Day of Month, Month, and Day of Week.
3. 3Read the plain-English description below the fields to confirm the schedule is correct.
4. 4Click Copy Expression and paste it into your crontab, CI pipeline, or cloud scheduler.

Cron Field Quick Reference

Each field accepts a specific value, a wildcard (*), a step value (*/5), a range (1-5), or a list (1,3,5). Combining these lets you express nearly any recurring schedule. The most common gotcha is day of month vs day of week — if you set both, most cron daemons will fire on either condition matching, not both simultaneously.

Reading a Cron Expression Field by Field

A cron expression is five space-separated fields that answer, in order: minute (0–59), hour (0–23), day of month (1–31), month(1–12), and day of week (0–6, with 0 as Sunday). A job runs whenever the current time matches every field. Each field accepts more than a single number: an asterisk (*) means “every value,” a step (*/5) means “every fifth value,” a range (9-17) is inclusive on both ends, and a list (1,3,5) picks specific values. So 0 9 * * 1-5 reads as “at minute 0 of hour 9, every day, in every month, on weekdays,” i.e. 9 AM Monday to Friday. The plain-English description this tool shows lets you confirm you have read the fields correctly before you rely on them.

The Day-of-Month vs Day-of-Week Trap

The most notorious source of cron bugs is the relationship between the two “day” fields. When you set both the day-of-month and the day-of-week to specific values, most cron implementations use OR logic, not AND — the job runs whenever either condition matches. So 0 0 13 * 5 does not mean “Friday the 13th”; it means “every 13th of the month and every Friday.” If you need a job on a specific weekday, leave day-of-month as *; if you need a specific date, leave day-of-week as *. Setting both is almost always a mistake unless you genuinely want the union of the two schedules.

Cron in the Cloud, and the Timezone Gotcha

Cron long ago outgrew the traditional Unix crontab. The same five-field syntax now schedules jobs in GitHub Actions, GitLab CI, Kubernetes CronJobs, AWS EventBridge, and countless other platforms — so learning it once pays off across your whole toolchain. There is one difference to watch closely: timezones. Classic Unix cron runs in the server's local timezone, but most cloud schedulers default to UTC, which is a frequent cause of jobs firing an hour or several hours off from what was intended. Whenever you deploy a schedule, confirm which timezone the platform uses, and remember that daylight-saving changes can shift local-time schedules too. Testing the next few fire times before going live is the simplest way to avoid these surprises.

A Brief History of Cron

Cron is one of the oldest tools in the Unix world still in daily use. Early versions appeared in the 1970s, and the design that persists today — a daemon that wakes up each minute and runs any jobs whose schedule matches the current time — was refined by Paul Vixie in the 1980s. “Vixie cron” became the basis for the cron found on most Linux systems, and its five-field syntax has proven so durable that it long outlived the specific machines it was written for.

The name comes from chronos, the Greek word for time, and the schedules themselves live in a file called the crontab (cron table). What makes cron remarkable is its longevity: a syntax designed for scheduling backups and log rotations on 1980s Unix servers is now the lingua franca of scheduling across cloud platforms and modern developer tools decades later, precisely because it is compact, expressive, and universally understood.

Cron vs Modern Alternatives

Classic Unix cron is simple and reliable, but it has limitations that spawned a range of alternatives worth knowing. On modern Linux, systemd timers offer a more powerful (if more verbose) option, with features cron lacks — running missed jobs after downtime, dependency management, and better logging integration. In the cloud, managed schedulers like AWS EventBridge, GCP Cloud Scheduler, and the scheduled workflows in GitHub Actions and GitLab CI run cron-style schedules without you maintaining a server at all.

For application-level work, job queues and schedulers such as the Quartz Scheduler (Java), Celery beat (Python), or cron libraries in Node.js provide scheduling inside your app, often with sub-minute precision and richer control. The good news is that nearly all of these adopted cron's five-field syntax, so the expression you build here transfers directly. Learning cron once genuinely pays off across the whole ecosystem — you are learning a standard, not just one tool.

Best Practices for Reliable Scheduled Jobs

Writing the cron expression is the easy part; making the scheduled job reliable is where experience shows. The most important principle is idempotency — design the job so that running it twice does no harm. Schedulers occasionally fire a job late, twice, or after a missed run, so a job that assumes it runs exactly once can corrupt data. A job that checks what work actually needs doing and does only that is far safer.

Two more habits prevent most production incidents. First, prevent overlap: if a job can sometimes run longer than its interval, a naive schedule will start a second copy while the first is still running, which can pile up and exhaust resources. Use a lock file or a scheduler feature to ensure only one instance runs at a time. Second, log and monitor: a silent cron job that fails is invisible until something downstream breaks. Capture output to a log, and for critical jobs use a “dead man's switch” monitor — a service that expects a check-in each run and alerts you if the job stops reporting. Combined with confirming the schedule's timezone and testing the next few fire times before deploying, these practices turn a fragile cron job into a dependable one.