⏰ Cron Expression Generator

How to Use a Cron Expression Generator to Schedule Tasks Like a Pro

If you have ever deployed a web application, set up a server, or worked with any kind of automated pipeline, you have almost certainly encountered cron — the Unix job scheduler that has been quietly running the internet's back-end machinery since the 1970s. At first glance, a cron expression like 0 9 * * 1-5 looks like someone fell asleep on the keyboard. But once you understand the structure, cron becomes one of the most expressive and reliable scheduling tools available to developers.

This tutorial walks you through cron expressions from the ground up: what each field means, how to build them visually, how to read them back in plain English, and the real-world patterns that appear over and over in production systems.

The Anatomy of a Cron Expression

A standard cron expression consists of five space-separated fields that together specify exactly when a job should fire. From left to right those fields are: minute, hour, day-of-month, month, and day-of-week. A six-field variant prepends a seconds field, which is used by schedulers such as Quartz (Java), Spring Boot, and many Node.js task runners, though it is not part of the traditional Unix cron format.

The five-field template looks like this:

┌───────────── minute (0–59)
│ ┌─────────── hour (0–23)
│ │ ┌───────── day of month (1–31)
│ │ │ ┌─────── month (1–12)
│ │ │ │ ┌───── day of week (0–6, Sunday=0)
│ │ │ │ │
* * * * *

Each field can hold a single value, a comma-separated list of values, a range with a hyphen, a step with a forward-slash, or the wildcard asterisk that means "every possible value."

Special Characters That Do the Heavy Lifting

Understanding the four special characters unlocks almost every scheduling pattern you will ever need:

The asterisk (*) means "every valid value." In the minute field * means every minute from 0 through 59. In the month field it means January through December. When all five fields are asterisks — * * * * * — the job runs once per minute, every minute, around the clock.

The slash (/) defines step values. Writing */5 in the minute field means "starting at 0, fire every 5 minutes" — so at :00, :05, :10, and so on. Writing 0 */4 * * * fires at midnight, 4 AM, 8 AM, noon, 4 PM, and 8 PM.

The hyphen (-) defines a range. 1-5 in the day-of-week field targets Monday through Friday. 9-17 in the hour field covers 9 AM through 5 PM. You can combine a range with a step: 0-30/10 in the minute field fires at :00, :10, :20, and :30.

The comma (,) creates a list of discrete values. 1,15 in the day-of-month field fires on the first and fifteenth. 0,6 in the day-of-week field targets Sunday and Saturday. You can freely mix ranges and lists: 1-5,0 means Monday through Friday plus Sunday.

Building Your First Ten Cron Expressions

The best way to internalize cron syntax is to translate common scheduling requirements into expressions manually, then verify them with a tool like the generator above.

Run every hour on the hour: 0 * * * * — minute is 0, everything else is wildcard.

Run every day at 2 AM for nightly backups: 0 2 * * * — minute 0, hour 2.

Run every weekday at 9 AM: 0 9 * * 1-5 — day-of-week restricted to Monday through Friday.

Run on the first of every month: 0 0 1 * * — midnight on the 1st of every month.

Run every 15 minutes during business hours on weekdays: */15 9-17 * * 1-5 — fires at :00, :15, :30, :45 during hours 9 through 17, only Monday–Friday.

Run twice a day, at 8 AM and 6 PM: 0 8,18 * * * — uses a comma list in the hour field.

Run the first Sunday of the month is where cron shows its limitations — standard cron cannot directly express "the first Sunday." The workaround is to combine a range in dom and dow, but results vary by cron implementation. This is the kind of edge case where a dedicated scheduler like AWS EventBridge or APScheduler is worth the overhead.

The Day-of-Month and Day-of-Week Interaction

One source of confusion that trips up many developers is how cron handles both the day-of-month and day-of-week fields simultaneously. When both fields contain specific values (not wildcards), most cron implementations treat the condition as an OR, not an AND. This means 0 0 15 * 1 fires at midnight on the 15th of every month, and also at midnight every Monday — not only on Mondays that fall on the 15th. If you want the intersection (only Mondays that are the 15th), you need to handle that logic in your script.

Six-Field Cron for Second-Level Precision

The Quartz scheduler, widely used in Java and Spring applications, prepends a seconds field to the standard five-field format. The six-field structure is sec min hour dom month dow. A Quartz expression of 0/30 * * * * ? fires every 30 seconds. The question mark (?) is a Quartz-specific placeholder meaning "no specific value," used to avoid ambiguity between the dom and dow fields when only one of them should be active.

When using the cron generator on this page, toggle to "6-field" mode to include the seconds field in your expression.

Common Pitfalls and How to Avoid Them

The most frequent mistake beginners make is confusing the hour field with a 12-hour clock. Cron uses a 24-hour format. 8 means 8 AM, and 20 means 8 PM. If you write 0 8 * * * expecting an evening run, your job fires at 8 AM instead.

The second common mistake is forgetting time zones. Cron always executes in the system's local time zone unless you explicitly configure otherwise. A job scheduled for 0 2 (2 AM) on a server running UTC will fire at a different local time than you might expect if your users are in another time zone. Cloud platforms like AWS EventBridge, GCP Cloud Scheduler, and GitHub Actions all support time zone configuration per scheduled job — use it.

The third pitfall is overlapping runs. If your job takes longer than the interval between runs — say you schedule a heavy database task every minute but it takes two minutes — multiple instances pile up. Always build concurrency controls into your scripts or configure your scheduler to skip if the previous instance is still running.

Using the Generator's Decode Feature

When you inherit a codebase or take over a server, you will often find cron expressions that nobody documented. The Decode tab in the generator above accepts any 5- or 6-field expression and translates it into plain English along with the next five scheduled run times. Paste in something like 30 6 1,15 * * and the tool will tell you it fires at 6:30 AM UTC on the 1st and 15th of every month, then show you exactly when those runs will happen relative to right now.

This makes auditing an unfamiliar system's scheduled jobs a much faster process. Run through each cron entry, paste it into the decoder, and within seconds you have a human-readable schedule you can document or refactor.

Where Cron Expressions Appear in the Modern Stack

Beyond the classic Unix crontab, cron syntax (or a close variant) appears in GitHub Actions workflow files under on.schedule.cron, AWS EventBridge rules, GCP Cloud Scheduler jobs, Kubernetes CronJob resources, Heroku Scheduler, Render's cron jobs, and most CI/CD systems. The core syntax is consistent enough that an expression you write for one platform usually works on another with minor adjustments — though always check whether the platform expects a five-field or six-field format and whether it uses 0 or 7 to represent Sunday.

Mastering cron expressions is one of those foundational skills that pays dividends across the entire lifecycle of a software project. Use the visual builder to draft, the decoder to verify, and the presets to short-circuit the most common scheduling tasks entirely.