Cron Expression Generator

Cron Expression Format

The standard Unix expression has five fields:

* * * * *
│ │ │ │ └── Day of week (0-7, 0 and 7 both mean Sunday)
│ │ │ └──── Month (1-12)
│ │ └────── Day of month (1-31)
│ └──────── Hour (0-23)
└────────── Minute (0-59)

Four operators cover almost everything you will ever need:

• * — every value
• , — a list, as in 1,15
• - — a range, as in 1-5
• / — a step, as in */15

Common Cron Expressions

Four Things That Catch People Out

Day of month and day of week are an OR, not an AND

This is the big one, and it is counter-intuitive enough that it bites experienced developers. It is stated explicitly in the crontab(5) man page, and the same behaviour is required by the POSIX specification for crontab, so it is not a quirk of one implementation.

0 0 13 * 5 does not mean "midnight on Friday the 13th". When both the day-of-month and day-of-week fields are restricted, cron runs when either matches. That expression fires at midnight on the 13th of every month and at midnight every Friday.

If you need a genuine AND, one of the two fields must be *. To get Friday the 13th, schedule it on day-of-month 13 and check the weekday inside your script.

Steps do not mean "every N", they mean "every Nth value in range"

*/5 in the minutes field works cleanly because 5 divides 60. */7 does not. It fires at minutes 0, 7, 14, 21, 28, 35, 42, 49 and 56 — then the hour rolls over and it fires again at 0, four minutes later rather than seven. Any step value that is not a divisor of the field's range produces this stutter at the boundary. Same problem with */7 in the day-of-month field, which resets on the 1st regardless of where the count had reached.

Cron does not know about your timezone unless you tell it

A crontab runs in the server's local time. A GitHub Actions schedule runs in UTC, always. EventBridge defaults to UTC but accepts a timezone. Kubernetes CronJobs use the controller's timezone unless a timeZone field is set. Make and n8n let you set the timezone per scenario or workflow, and the default is not necessarily the one you expect.

The result is a job that runs an hour out for half the year, or one that a colleague in a different office insists is running at the wrong time. Decide deliberately whether the schedule should track local time or absolute time, and write the answer in a comment beside the expression.

Daylight saving does something surprising twice a year

When clocks go forward, jobs scheduled inside the skipped hour do not run at all. When clocks go back, jobs inside the repeated hour may run twice. For a 2am backup this matters. Schedule anything sensitive outside the 1am–3am window, or run it in UTC where the problem does not exist.

Not All Cron Is Five Fields

Quartz and AWS EventBridge use six or seven fields, with seconds at the front and year optionally at the end. They also support ? to mean "no specific value", which is how they resolve the day-of-month versus day-of-week ambiguity, plus L for last and # for "nth weekday of the month". 0 0 12 L * ? in Quartz is the last day of the month at noon — the schedule standard cron cannot express.

Shorthand macros work in most Unix crons: @hourly, @daily, @weekly, @monthly, @yearly and @reboot. They are clearer than the equivalent expression and worth using where they fit.

Where Cron Expressions Turn Up

• Linux and Unix — crontab for scheduled scripts
• GitHub Actions — schedule.cron in workflow YAML, UTC only
• AWS Lambda — EventBridge scheduled rules, six fields
• Make and n8n — scenario and workflow scheduling
• Kubernetes — CronJob resources
• Heroku, Railway and similar — scheduler add-ons

This comes up constantly in scheduled automations. n8n Self-Hosted Setup covers scheduled backup jobs on your own instance, and Make.com Data Store Tutorial covers scheduled sync jobs that track their own last-run timestamp, which is where the timezone question stops being academic.

If you are writing the crontab entry itself, the Docker Compose Generator is useful for the container that will run it, and the Regex Tester for the log-matching you will inevitably need once the job starts failing quietly.

Frequently Asked Questions

Why does my cron job work when I run the script manually but not on a schedule?

Almost always the environment. Cron runs with a minimal PATH and none of your shell profile, so a command that resolves fine in your terminal is simply not found. Use absolute paths for every binary and file in the crontab entry, and redirect output to a log file so the failure is visible rather than silently mailed nowhere.

What happens if a job is still running when the next one is due?

Standard cron starts the new one anyway, so two copies run concurrently and can corrupt each other's work. Cron has no built-in locking. Wrap the command in flock, or have the script take a lock file and exit if it is already held. Overlapping runs are the most common cause of duplicated records in scheduled sync jobs.

How do I run something on the last day of the month?

Standard cron cannot express it. The usual workaround is to run daily and have the script exit unless tomorrow is the 1st. Quartz and EventBridge support L directly, and most automation platforms offer a "last day of month" option in their scheduling UI.

Why does my crontab entry with a date break?

The % character has a special meaning in crontab: it terminates the command and everything after becomes standard input. A date +%Y-%m-%d in a crontab line needs each % escaped as \%, or the whole thing moved into a script file where the problem disappears.

When Cron Stops Being Enough

Cron is excellent for simple recurring tasks on a machine you control. It has no retries, no dependency handling, no visibility into whether a run succeeded, and no memory of what it did last time. Once any of those matter, move to a scheduler that has them — a workflow platform, Temporal, or Celery Beat — rather than layering shell scripts around a crontab.

Book a consultation if your scheduled jobs have reached that point, or take the work on through Upwork.