Write a Cron Expression That Runs When You Expect

A cron expression is a short string of five fields that tells a scheduler when to run a job, and the Best Answer Hub Cron Expression Generator builds it, explains it in plain English, and shows the next run times so you can confirm the schedule before it ships. This guide explains what each field means, what the asterisk, comma, hyphen, and slash do, the day-of-month and day-of-week trap that runs jobs on days you never intended, why the same expression can be rejected on a different system, and how timezones and daylight saving quietly shift when a job fires.

What is the Best Answer Hub Cron Expression Generator?

The Best Answer Hub Cron Expression Generator is a single-page tool that builds a cron schedule from click-to-set fields and preset buttons, then shows a plain-English description and the next ten times the job will run. You can switch between standard 5-field cron, a 6-field variant with seconds, and Quartz 7-field cron, and you can paste an existing expression to have it explained. Every calculation runs in your browser with plain JavaScript, so nothing is sent to a server and it keeps working with the internet switched off. It needs no account and shows no ads. The tool sits in the Best Answer Hub Developer Toolbox and the wider Tools hub, is built and maintained by Shahbaz Ali Malik, and stays free because Best Answer Hub is funded by optional paid assessments rather than advertising.

What do the five fields in a cron expression mean?

A standard cron expression has five fields separated by spaces, read left to right as minute, hour, day of month, month, and day of week. The allowed ranges are minute 0 to 59, hour 0 to 23, day of month 1 to 31, month 1 to 12 (or the names JAN to DEC), and day of week 0 to 7, where both 0 and 7 mean Sunday (or the names SUN to SAT). These ranges are defined in the Linux crontab(5) manual page and the POSIX crontab specification. The Best Answer Hub Cron Expression Generator labels every field and validates the values as you type, so an out-of-range entry like 25 in the hour field is caught before you copy the string.

What do the asterisk, comma, hyphen, and slash mean?

Four symbols do almost all the work in a cron field. An asterisk means every valid value, so an asterisk in the minute field means every minute. A hyphen sets an inclusive range, so 9-17 in the hour field means 9 AM through 5 PM. A comma lists separate values, so 1,15 in the day-of-month field means the 1st and the 15th. A slash sets a step, so */15 in the minute field means every 15 minutes. These definitions come straight from crontab(5). One catch worth knowing: a step is only an even cadence when it divides its range cleanly. */15 works because 15 divides 60, but */40 fires at minute 0 and minute 40, then resets at the top of the next hour, a 20-minute gap rather than a steady 40 (Wikipedia).

Why does my cron job run on the wrong day of the month?

The usual cause is the day-of-month and day-of-week rule: when both of those fields are set to something other than an asterisk, standard cron runs the job when either one matches, not when both match. The crontab(5) man page states it plainly: "If both fields are restricted (i.e., do not contain the '*' character), the command will be run when either field matches the current time." The POSIX standard specifies the same OR behavior. So 0 0 13 * 5 does not mean "Friday the 13th"; it means midnight on the 13th of every month, and also midnight every Friday. To get a true "Friday the 13th", one of the two day fields has to stay unrestricted and the logic handled another way.

Cron will not warn you that a schedule runs more often than you meant. The plain-English preview is what catches the wrong-day trap before it reaches production.

What are the most common cron schedules?

Most real schedules are variations on a handful of patterns, and each maps to a plain-English sentence you can check at a glance. The table below lists the ones people reach for most, all in standard 5-field form. Every row is a valid expression you can paste into a Linux crontab, a Kubernetes CronJob, or a GitHub Actions schedule. The Best Answer Hub Cron Expression Generator carries preset buttons for these exact cases, and it prints the next ten run times so you can confirm the cadence rather than trust the string.

Why won't my cron expression run on another system?

The usual reason is field count: standard Unix cron uses five fields, but several popular schedulers add fields, so an expression that is valid in one place is rejected in another. The Quartz scheduler used across Java and .NET expects six or seven fields, adding a leading seconds field and an optional trailing year, and it uses a ? character that plain cron does not have (Quartz docs). Spring uses six fields with leading seconds (Spring docs). AWS EventBridge uses six fields with a trailing year and forbids an asterisk in both day fields at once (AWS docs). Kubernetes CronJobs, by contrast, use plain 5-field cron (Kubernetes docs). The day-of-week numbers differ too: Unix counts Sunday as 0, while Quartz and EventBridge count Sunday as 1.

The Best Answer Hub Cron Expression Generator handles this by letting you pick the flavor before you build, so the string you copy matches the system you are pasting into. If a schedule that worked locally suddenly errors on deploy, the field count is the first thing to check.

Do cron jobs use UTC, and what happens at daylight saving?

Classic cron runs on the machine local time zone, not UTC, which is why the same expression fires at a different wall-clock moment on differently configured hosts. Around daylight saving transitions the behavior is specific: the cron(8) man page notes that when clocks move forward, a specific-time job in the skipped hour runs immediately, and when clocks move back, cron avoids running the same job twice. Jobs that run more often than hourly are unaffected. To sidestep the whole issue, many teams schedule production jobs in UTC, which never observes daylight saving. Kubernetes supports a .spec.timeZone field so a CronJob can name an explicit IANA zone rather than inheriting the controller local time (Kubernetes docs).

How is it different from crontab.guru?

The difference is that crontab.guru is a bare editor for a single standard expression, while the Best Answer Hub Cron Expression Generator adds a click-to-build interface, presets, next-run previews, and support for the 6-field and Quartz flavors, all without leaving your browser. Crontab.guru describes itself as "the quick and simple editor for cron schedule expressions by Cronitor" and funnels toward Cronitor's paid monitoring product (crontab.guru). Other popular generators emit Quartz strings by default: CronMaker states its output is "based on Quartz cron format" (CronMaker), which will not paste into a normal Linux crontab. The table sets the usual experience next to this one.

Common questions about cron expressions

Keep going

Sources

• Linux man-pages, crontab(5) (five fields and ranges; special characters; the day-of-month/day-of-week OR rule; @-string macros).
• Linux man-pages, cron(8) (local time zone; daylight-saving behavior for skipped and repeated hours).
• The Open Group Base Specifications Issue 7 (POSIX), crontab (field definitions; the either-matches day rule).
• Quartz Scheduler, CronTrigger tutorial (six or seven fields; seconds and year; the ? character; Sunday = 1).
• Spring Framework, CronExpression (six fields with leading seconds).
• AWS, EventBridge schedule expressions (six fields with year; asterisk not allowed in both day fields).
• Kubernetes, CronJob (standard 5-field cron; optional .spec.timeZone).
• Cronitor, crontab.guru (the quick and simple editor for cron schedule expressions).
• CronMaker, CronMaker (output based on Quartz cron format).
• Wikipedia, Cron (step values are an even cadence only when they divide the range).

Jump into the tools: Cron Expression Generator, Developer Toolbox, JSON Formatter, and all Tools.