Cron Expression Cookbook: 25 Schedules People Actually Search For

Updated 2 Sep 2026 · 9 min read

Cron's five fields are simple in theory and a constant source of off-by-one mistakes in practice. Below are 25 real schedules — the ones people actually type into a search box, not a tour of every possible field combination — each with the exact expression, a one-line explanation, and a live link into Cron Master prefilled with that schedule so you can see its next 10 run times before you commit it to a crontab.

Quick-copy reference

Worked examples

1. Every 6 hours, but not starting at midnight

The most common surprise with step syntax: */6 in the hour field doesn't mean "every 6 hours from whenever this job starts running." It means "every hour value that's a multiple of 6" — 0, 6, 12, 18. If you actually want the cycle offset (say, a job that should first run at 3am so it doesn't collide with a midnight backup), you have to abandon the step syntax and list the exact hours:

# Runs at 0, 6, 12, 18 — not what you want if 3am was the intent
0 */6 * * *

# Runs at 3, 9, 15, 21 — the actual offset schedule
0 3,9,15,21 * * *

2. The last day of the month, without a native token

This is the single most-searched cron schedule that standard cron simply cannot express directly. Day-of-month is a fixed field with no concept of "however many days this particular month has" — there's no way to write one expression that means the 28th in February and the 31st in a month like January. Two portable workarounds, depending on what your scheduler supports:

• Run on the 1st of the next month instead, and process "yesterday." Schedule 0 0 1 * * and have the job compute the last day of the previous month as its target date. This is the most portable option — every cron implementation supports it.
• Run on each candidate date and self-check. Schedule 0 0 28-31 * * — note this fires on every date in that range that the month actually has, so four times in a 31-day month, three in a 30-day month, and once (or twice in a leap year) in February — and have the job itself check "is tomorrow the 1st?" before doing real work, exiting immediately if not. The guard runs on each of those firings, so keep anything with side effects behind it, not before it.

If your specific scheduler is Quartz, Jenkins, or a cron fork that documents an L token in the day-of-month field, that solves it natively — but that's a scheduler-specific extension, not standard POSIX cron, so verify against your own tool's docs rather than assuming it's portable.

3. Why "the first Monday of the month" isn't one field combination

A schedule like 0 9 1-7 * 1 looks like it should mean "9am on the first Monday of the month" — restrict the day-of-month to the first week, restrict the day-of-week to Monday. It doesn't work that way. When both the day-of-month and day-of-week fields are restricted (anything other than *), standard cron treats them as an OR, not an AND: this expression actually fires at 9am on the 1st through the 7th of every month and at 9am on every Monday, which in most months is six or seven runs, not one.

# Looks like "first Monday of the month at 9am" — it isn't.
# Fires on the 1st–7th (any weekday) AND every Monday (any date).
0 9 1-7 * 1

The portable fix is to run daily and check inside the job: schedule 0 9 1-7 * * (9am, every day 1st–7th) and have the job itself verify new Date().getDay() === 1 before doing real work, so it only actually executes on whichever of those seven days is the Monday.

Common gotchas, in one place

1. Day-of-month and day-of-week combine with OR, not AND, whenever both are restricted. See worked example 3 above — this single misunderstanding accounts for a large share of "why did my cron job run on the wrong day" reports.
2. Cron runs on the server's system timezone, not UTC and not the browser reading this page. Check with date on the actual machine, or set an explicit TZ= line in the crontab if your implementation supports it — don't assume.
3. Step syntax (*/N) always counts from the field's zero point, never from whenever the job happens to start. */6 in the hour field is 0/6/12/18, full stop — see worked example 1 for the offset workaround.
4. There's no native "last day of month" token in standard cron. See worked example 2 for the two portable workarounds.
5. A missing environment does not mean a broken expression. If a job's schedule fires correctly (confirm with Cron Master's execution list) but the job itself fails, the cron expression isn't the bug — check PATH and other environment variables, since cron doesn't inherit your interactive shell's environment.

← Back to Blog