What is a Cron Expression? Syntax, Fields & Examples

A cron expression is a compact string of five fields that tells a scheduler exactly when to run a repeating task. Each field controls one unit of time — minute, hour, day of month, month, and day of week — and together they describe a schedule like "every day at 3 AM" or "every 15 minutes on weekdays." Cron expressions power scheduled jobs on Linux servers, CI pipelines, and countless cloud platforms.

What is a cron expression?

The name comes from cron, the time-based job scheduler that has shipped with Unix and Linux systems for decades. A cron job is any task cron runs automatically on a schedule, and the cron expression is the line that defines that schedule. Instead of writing "run this at the top of every hour," you write a five-field pattern the scheduler can match against the current time.

Because the format is so compact, it has spread far beyond classic Unix cron. You will find the same syntax in Kubernetes CronJobs, GitHub Actions, AWS EventBridge, and most background-job libraries. Learn it once and you can schedule almost anything.

The five cron fields

A standard cron expression has exactly five fields, separated by spaces, read left to right:

So the expression 30 9 * * 1 reads as: minute 30, hour 9, any day of month, any month, on day-of-week 1 (Monday) — in other words, every Monday at 9:30 AM.

Special characters

The power of cron comes from a small set of special characters you can place in any field:

• * (asterisk) — matches every value. * * * * * runs every minute.
• , (comma) — a list of values. 0,30 in the minute field means at :00 and :30.
• - (hyphen) — a range. 1-5 in the day-of-week field means Monday through Friday.
• / (slash) — a step. */15 in the minute field means every 15 minutes.

These combine freely. 0 9-17 * * 1-5 means "at the top of every hour from 9 AM to 5 PM, Monday through Friday" — a classic business-hours schedule.

Common cron expression examples

Most real-world schedules are variations on a handful of patterns:

If an expression ever looks cryptic, paste it into a cron parser to see a plain-English description and the next run times.

How to read a cron expression step by step

Take 15 14 1 * * and decode it field by field:

1. Minute = 15 — at 15 minutes past the hour.
2. Hour = 14 — during the 2 PM hour.
3. Day of month = 1 — only on the 1st.
4. Month = * — every month.
5. Day of week = * — regardless of weekday.

Put together, the job runs at 2:15 PM on the first day of every month. Reading each field in isolation and then combining them is the reliable way to interpret any expression.

The day-of-month vs day-of-week gotcha

One rule surprises almost everyone: if you specify both day of month and day of week (neither is *), most cron implementations treat them as an OR, not an AND. So 0 0 1 * 1 runs at midnight on the 1st of the month or any Monday — not only on Mondays that fall on the 1st. When you need a precise weekday-and-date match, handle that logic inside your script rather than in the expression.

Time zones and cron

Standard cron runs in the server's local time zone. If your server clock is UTC, every schedule is in UTC; if it is set to New York time, jobs shift with daylight saving. That shift causes two classic bugs: during the spring-forward hour a job can be skipped, and during fall-back it can run twice. To sidestep the ambiguity, many teams set their cron servers to UTC and convert to local time only when displaying results. A timestamp converter helps when you need to reason about when a UTC schedule actually fires locally.

Seconds and other extensions

Classic cron has no seconds field, so the finest resolution is one minute. Some schedulers — Quartz, many Node.js libraries, and certain cloud services — add a sixth field for seconds at the front, turning * * * * * * into "every second." Others add non-standard characters like L (last day), W (nearest weekday), and # (nth weekday of the month). These are handy but not portable, so check your platform's documentation before relying on them.

Where cron expressions are used

Once you recognise the five-field pattern, you will spot it everywhere:

• Linux crontab — the original home of cron, scheduling system and user jobs.
• Kubernetes CronJobs — run containers on a schedule inside a cluster.
• CI/CD pipelines — GitHub Actions and GitLab CI trigger scheduled workflows with cron.
• Cloud schedulers — AWS EventBridge, Google Cloud Scheduler, and Azure use cron-style rules.
• Application job queues — background-task libraries in most languages accept cron strings.

Best practices for cron jobs

• Keep jobs idempotent. A job may run twice around daylight-saving changes, so design it to be safe to repeat.
• Run servers in UTC. It removes an entire class of time-zone bugs.
• Log every run. Capture start, finish, and exit status so you can tell a silent failure from a skipped run.
• Avoid overlap. If a job can run long, add a lock so the next scheduled run does not start before the previous one finishes.
• Test the expression first. Confirm the schedule with a parser before deploying it to production.

How to build and check cron expressions online

You do not need to memorise the syntax or wait for the next scheduled run to verify it. These free, browser-based tools work instantly and privately:

• Cron Parser — translate a cron expression into plain English and preview upcoming run times.
• Cron Builder — assemble a valid expression from simple dropdowns, no memorisation required.
• Timestamp Converter — convert the resulting run times between Unix time, UTC, and local time.

Conclusion

A cron expression packs a complete schedule into five short fields: minute, hour, day of month, month, and day of week. Master the four special characters — *, ,, -, and / — and you can express almost any recurring schedule, from every minute to once a year. Watch out for the day-of-month/day-of-week OR rule and for time-zone surprises, and lean on a parser to confirm an expression does exactly what you intend before it goes live.