Cron Expressions Explained

Software developers frequently need to run tasks automatically. Whether you're scheduling database backups, generating daily reports, syncing data between APIs, performing cache cleanup, or rotating logs, automation is essential for reliable systems.

The industry standard mechanism for defining these time-based schedules is the Cron expression.

What Is Cron?

Cron is a time-based job scheduler commonly found in Unix and Unix-like operating systems. The cron daemon runs continuously in the background, checking a configuration table (the crontab) to see if any scheduled tasks are due to run in the current minute.

This distinction is important because while "Cron" refers to the system, developers usually interact directly with "Cron expressions" to define the rules for their jobs.

What Is a Cron Expression?

A Cron expression describes when a scheduled task should run. It is a compact string of fields separated by spaces.

For example:

In a standard five-field Cron interpretation, this expression translates to:

"Every 5 minutes"

Cron Expression Syntax

The standard Cron format consists of five fields. Here is the visual structure:

Understanding the Five Cron Fields

Minute

Range: 0–59

The exact minute(s) of the hour the job will run.

# Examples *       (Every minute) 0       (At minute 0) 15      (At minute 15) */5     (Every 5 minutes) 1,15,30 (At minutes 1, 15, and 30) 1-10    (Every minute from 1 to 10)

Hour

Range: 0–23

The exact hour(s) of the day. Uses a 24-hour clock.

# Examples *       (Every hour) 0       (Midnight) 12      (Noon) */2     (Every 2 hours) 9-17    (Every hour between 9 AM and 5 PM)

Day of Month

Typical Range: 1–31

The specific day of the month. Note that valid values depend on the actual month (e.g., February has 28/29 days).

Month

Typical Range: 1–12

The specific month of the year. Some Cron implementations also support three-letter month names (JAN, FEB, etc.).

# Examples 1       (January) 6       (June) 12      (December) 1,6,12  (January, June, and December)

Day of Week

Typical Range: 0–7

The day of the week. In many common Unix implementations, 0 represents Sunday. Often, 7 also represents Sunday. Some implementations support names:

MON TUE WED THU FRI SAT SUN

Cron Field Reference Table

Cron Special Characters

Cron expressions use special characters to define advanced scheduling logic beyond single values.

* Wildcard

Meaning: All allowed values for that field.

/ Step

Meaning: Defines step values/intervals.

Runs every five minutes.

- Range

Meaning: Defines a contiguous range of values.

Runs at minute 0 past every hour from 9 (9 AM) to 17 (5 PM).

, List

Meaning: Specifies multiple individual values.

Runs exactly at 9:00 AM, 12:00 PM, and 6:00 PM.

Combination

You can combine these characters for complex logic.

Every 15 minutes, between 9 AM and 5 PM, Monday through Friday.

How to Read a Cron Expression

The easiest way to read a Cron expression is step-by-step from left to right: Minute → Hour → Day of Month → Month → Day of Week.

Take this expression:

Let's break it down:

• Minute: 30 (At minute 30)
• Hour: 9 (At hour 9, which is 9 AM)
• Day of Month: * (Every day)
• Month: * (Every month)
• Day of Week: 1-5 (Monday through Friday)

Therefore, the final human-readable schedule is:

"Runs at 9:30 AM, Monday through Friday."

Common Cron Expression Examples

How to Create a Cron Expression

Building a Cron expression follows a simple, repeatable 7-step process.

Practical Developer Schedules

Advanced Cron Expressions

Weekday business hours

Every 15 minutes between 9 AM and 5 PM, Monday through Friday.

Multiple specific hours

Exactly at 9 AM, 1 PM, and 6 PM every day.

Specific months (Quarterly)

At 9:00 AM on the 1st day of January, April, July, and October.

Cron Day-of-Month and Day-of-Week Behavior

This is one of the most confusing aspects of standard Cron behavior. Let's look at this expression:

You might assume this means: "Run at 9 AM on the 1st of the month, but only if it is a Monday."

However, traditional Cron implementations treat the day-of-month and day-of-week fields with an OR-style relationship when both are restricted (i.e., when neither is *).

Always test complex day matching. Note that behavior can vary by implementation—some custom schedulers might treat it as an AND relationship.

Cron Time Zones and Scheduling

A Cron expression describes a time, but it does not inherently mean "your local time." Cron schedules run according to the environment's configured time zone.

• Server timezone: By default, Linux cron uses the system timezone.
• Containers: Docker containers often default to UTC unless specifically configured.
• Cloud Schedulers: AWS EventBridge, GCP Cloud Scheduler, etc., usually allow you to define the timezone along with the expression.

Daylight Saving Time (DST)

If your server uses a local timezone (like EST or PST), Daylight Saving Time will cause massive problems:

• Missing times: When clocks spring forward (e.g., from 1:59 AM to 3:00 AM), jobs scheduled between 2:00 AM and 2:59 AM will not run at all.
• Repeated times: When clocks fall back (e.g., from 2:59 AM back to 2:00 AM), jobs scheduled in that hour will run twice.

Standard Cron vs Quartz Cron

Cron syntax is not perfectly universal. The two most common variants you will encounter are standard Unix Cron and Quartz Scheduler (commonly used in Java ecosystems).

Standard Cron (5 fields):

Quartz Cron (6 or 7 fields):

Common Cron Mistakes

Avoid these frequent developer pitfalls:

1. Miscounting the five fields: Accidentally providing 4 or 6 fields in a standard Cron setup.
2. Confusing minute and hour: Writing * 0 * * * (every minute of midnight) instead of 0 * * * * (top of every hour).
3. Using seconds in standard Cron: Standard Cron does not support seconds. The first field is Minute.
4. Assuming Cron uses local time: Cron uses the execution environment's timezone.
5. Forgetting timezone configuration: Not explicitly setting the timezone in cloud schedulers.
6. Misunderstanding */5: Thinking it means "exactly 5 minutes from now" instead of "on minutes divisible by 5" (e.g., 10, 15, 20).
7. Confusing ranges and lists: Using 9,17 (9 AM and 5 PM) when you meant 9-17 (9 AM to 5 PM).
8. Incorrect day-of-week numbering: Forgetting if your system uses 0 or 7 for Sunday.
9. Ignoring day-of-month/day-of-week semantics: Forgetting the OR-relationship (e.g., 0 0 1 * MON).
10. Copying Quartz syntax into standard Cron: Using the ? character where it isn't supported.
11. Forgetting DST behavior: Scheduling a critical job at 2:30 AM on a server using local time.
12. Not testing schedules: Deploying complex expressions without validating them in a Cron parser first.
13. Assuming every Cron implementation is identical: Kubernetes, Vixie Cron, BusyBox, and Jenkins all have slight variations.
14. Running expensive jobs too frequently: Creating overlapping executions because the job takes longer than the interval.
15. Forgetting overlapping executions: Not implementing lock files for jobs that cannot safely run concurrently.
16. Not logging Cron job output: Failing to redirect stdout and stderr, meaning failures fail silently.
17. Using relative paths: Cron usually runs in a restricted shell. Always use absolute paths to scripts and files.
18. Assuming environment variables are identical: Cron does not load your full user profile (e.g., .bashrc). PATH variables might be missing.
19. Ignoring permissions: The cron daemon runs as a specific user; ensure that user has execute permissions.
20. Not accounting for server/container timezone: Migrating a container to a different cloud region and accidentally changing schedule times.

Cron Best Practices (Reliability and Security)

A correct Cron expression does not guarantee a reliable job. Follow these operational best practices:

• Keep expressions readable: If it's overly complex, consider running it more frequently and handling the time logic inside the script itself.
• Comment complex schedules: Always add a plain-English comment above your crontab entry.
• Test expressions before production: Use a Cron Parser to visualize upcoming dates.
• Document timezone assumptions: Clearly state in documentation if the schedule expects UTC.
• Use absolute paths where appropriate: Never rely on ./script.sh in a crontab.
• Capture logs: Always redirect output (e.g., > /var/log/myjob.log 2>&1).
• Make jobs idempotent: A job should be safe to run twice accidentally without causing data corruption.
• Prevent overlapping executions: If a job runs every 5 minutes but takes 10 minutes, multiple instances will run simultaneously. Use lock files, job queues, or distributed locks to prevent this.
• Avoid sensitive data in command arguments: Do not pass passwords directly in the crontab command line (e.g., --password=secret), as they can be seen in process lists. Use environment variables or secure credential stores.

How to Test a Cron Expression

Never deploy a complex Cron expression directly to production without verifying it.

Using the UnixlyTools Cron Parser, you can type your expression and immediately see:

• A plain-English description of the schedule.
• A breakdown of each individual field.
• A list of the next upcoming execution dates (to verify it matches your intent).

Frequently Asked Questions