Cron Expression Tips and Common Mistakes to Avoid

The most common cron mistakes are confusing the minute and hour fields, misusing the day-of-month and day-of-week combination, and accidentally writing a schedule that fires every minute — all of which you can catch before deploying by checking the plain-English summary and next-run list in a cron parser. A schedule that looks right can still behave in surprising ways, so treat every expression as guilty until verified.

These are the practices that keep scheduled jobs predictable, drawn from the failure modes that bite teams most often.

Common mistakes and how to spot them

The parser’s next-five-runs list is the fastest way to catch these. If the times are not what you expect, the expression is wrong — no need to wait for the job to misfire in production.

The day-of-month plus day-of-week trap

This is the single most misunderstood rule in cron. When you set a specific value in both the day-of-month (field 3) and the day-of-week (field 5), the job runs when either condition is true, not both together. So 0 0 1 * 1 does not mean "the first of the month if it is a Monday" — it means "on the 1st of every month, and also every Monday." If you only need one condition, leave the other field as an asterisk.

Best-practice settings

• Pin the minute. Always give the minute field an explicit value unless you genuinely want the job every minute of that hour. A stray asterisk is the top cause of runaway jobs.
• Use steps for intervals. Prefer */15 over a long list like 0,15,30,45 — it is easier to read and less error-prone.
• Constrain to business hours. Ranges such as 9-17 in the hour field keep noisy jobs out of the night.
• Name your months and days. MON and JAN are harder to fat-finger than numbers and read more clearly in review.
• Avoid stacking peaks. If many jobs fire at 0 0 * * *, spread them across minutes to reduce midnight load.

Troubleshooting a job that never runs

When a schedule silently does nothing, work through these checks. First, confirm the field order — a swapped minute and hour is the usual culprit. Second, validate ranges: an hour of 24 or a month of 0 is out of bounds and the parser will flag it. Third, remember time zones: the parser shows next runs in your local zone, but your server may run in UTC, so a job you expect at 9 AM local could be scheduled for a different wall-clock time on the box. Paste the expression, read the summary, and compare the next-run times against your intent.

Try the Cron Expression Parser — free and 100% in your browser.

FAQ

Why does my job run twice on some days?

You have restricted both the day-of-month and day-of-week fields, so cron fires on either match. Set one of them back to an asterisk to get single, predictable runs.

Is Sunday 0 or 7 in cron?

Most cron implementations accept both 0 and 7 for Sunday. To stay portable and unambiguous, use the name SUN or stick with 0, and verify with the parser’s breakdown.

How do I stop a job from firing every minute by accident?

Give the minute field a concrete number. An asterisk in position one means "every minute," which combined with a fixed hour still fires 60 times. Change * 9 * * * to 0 9 * * *.

My cron looks correct but runs at the wrong time. Why?

Almost always a time-zone mismatch between your local machine and the server. The parser computes next runs in your local zone; adjust your expectation to the environment the crontab actually executes in.

Related free tools

• Regex Tester — debug patterns before they hit production.
• Timestamp Converter — reconcile dates and epochs.
• Unix Timestamp Converter — read raw log timestamps.
• JSON Formatter — clean up scheduler config files.

Built by ByteVancer

ByteTools is a free product of ByteVancer, a software and web development studio building web apps, SaaS, and custom software. If flaky cron jobs are costing your team reliability, ByteVancer can help design automation that runs exactly when it should — explore their services to see how.