Cron Syntax Demystified: Building Reliable Scheduled Tasks Without the Headaches

By Marcus Vane · October 15, 2026 · Developer Tools

Five fields, a handful of operators, and a long list of subtle traps. A clear walkthrough of cron syntax, the environments it runs in, and the failures that catch people by surprise.

Cron is the scheduling language that has quietly run background tasks on Unix systems for decades, and its syntax is compact enough to fit in a single line and cryptic enough to misread regularly. The cost of a misread cron expression is real: a backup that runs at the wrong hour, a report that fires every minute instead of every week, or a task that never runs at all because the environment it executes in is not the one you tested in. The good news is that the syntax is small, and the traps, while numerous, are well known.

In this article:

The five fields explained

A standard cron expression has five fields, read left to right: minute, hour, day of the month, month, and day of the week. Each field constrains when the task runs. A star in a field means every value, so five stars means every minute of every day. The fields are separated by spaces, and the expression is followed by the command to run. Some modern schedulers add a sixth field for seconds at the start, which is a common source of confusion when moving between systems.

Operators: stars, lists, ranges and steps

Within each field, several operators combine to express almost any schedule. A comma separated list, such as "0,15,30,45", runs at each listed value. A hyphenated range, such as "9-17", runs at every value in the range. A step value, written as a slash after a range or star, runs at intervals, so "*/15" in the minute field means every fifteen minutes. These combine, so "9-17/2" in the hour field means every two hours between nine and five. The day of month and day of week fields have a special interaction: when both are restricted, cron runs when either matches, which is a frequent source of surprise.

Worked examples translating schedules

Example one: a daily backup at two in the morning

To run a backup every day at two in the morning, set the minute field to zero and the hour field to two, with stars for the other three fields: "0 2 * * *". The task fires once per day at the same moment. Note that this is two in the morning in the server's time zone, which is the first thing to confirm when a backup appears to run at the wrong time.

Example two: every weekday at nine thirty

A report that runs Monday to Friday at nine thirty uses minute thirty, hour nine, stars for day of month and month, and one through five for day of week: "30 9 * * 1-5". The day of week field counts Sunday as zero or seven, and Monday as one, which is the convention most people get wrong the first time.

Example three: the last day of the month

Cron has no direct last day of month token in the standard syntax, which is a notorious gap. The common workaround is to run on the twenty eighth, twenty ninth, thirtieth and thirty first and have the script itself check whether the date is the final day of the month, exiting early otherwise. Some extended cron implementations support an L token for the last day, but it is not portable, so the script side check is the reliable approach.

The environment trap

The single most common reason a cron task works when run manually but fails when scheduled is the environment. A cron job runs with a minimal environment, often without the path, shell configuration and environment variables your interactive shell provides. A command that relies on a program in a non standard location, on a loaded virtual environment, or on an environment variable set in your profile will fail silently under cron. The fix is to make the command self contained: use absolute paths to every executable, source the needed environment inside the script, and write logs to a known file so you can see what happened.

Common mistakes

FAQ: cron edge cases

What happens when a cron job is still running at the next scheduled time?

Standard cron starts a new instance regardless, so long running tasks can overlap and cause contention. If overlap is a problem, use a lock file in the script to prevent concurrent execution, or a scheduler that supports concurrency limits.

Does cron handle daylight saving transitions?

Poorly. A job scheduled at two thirty in the morning may not run or may run twice on a transition day, depending on the system. Avoid scheduling critical jobs in the transition window, and prefer UTC for cron schedules to avoid the issue entirely.

How do I test a cron expression safely?

Use a cron expression explainer to see the next several firing times in plain language before deploying, and write the schedule into a script that logs each run. Confirm the first few firings against the log before trusting it.

Wrapping up

Cron is five fields and a handful of operators, and almost every failure traces back to a misread field, an unexpected day of week convention, or a missing environment. Write self contained commands with absolute paths, log the output, confirm the time zone, and check the next firing times before you trust the schedule. Do that and cron becomes the reliable workhorse it was designed to be.

Build and explain cron expressions with the next firing times.

Try the Cron Job Generator tool.

SwiftMultiTool — free online tools for everyone. Home · Blog · About · FAQ · Contact