What are the fields in a cron expression?

Five fields: minute, hour, day of month, month, and day of week. The terse syntax of asterisks, commas, and slashes is what a generator helps you get right without memorizing it.

What is the most common cron mistake?

Setting both day-of-month and day-of-week — standard cron treats that as "either," not "both." Time zones are another trap, since classic cron runs in the server's zone and some platforms, such as GitHub Actions, default to UTC.

Should I verify a generated cron expression?

Yes — confirm it means what you intend, ideally via a plain-English readback, and check it against your scheduler's exact dialect. A small error can run a job at the wrong time for days unnoticed.

Cron Expression Generator: Scheduling Jobs Without the Guesswork

The Cryptic Five Fields

A cron expression schedules recurring tasks using five fields — minute, hour, day of month, month, and day of week — and the terse syntax of asterisks, commas, and slashes trips up even experienced developers. A cron expression generator gives you valid hourly, daily, weekly, or monthly expressions, each with a plain-English description. Use one as a template: adjust the numbers to the time you want, and the field order is already right.

The stakes are real. A misread expression can run a job every minute instead of every day, or never run it at all, and you often only discover the mistake when something breaks or a bill arrives. Getting the expression right the first time matters.

The Fields and Their Traps

Each field has its quirks. The day-of-month and day-of-week fields are a classic trap — in standard cron, if both are restricted, the job runs when either matches. So 30 4 1,15 * 5 runs at 4:30 on the 1st and 15th and also every Friday, which surprises people. Step syntax (like */15 for every fifteen minutes) and ranges (like 1-5 for Monday to Friday) are powerful but easy to misjudge; a cron schedule explainer spells out common patterns in plain English.

Time zones are another pitfall. Classic cron runs in the server's local time zone, while GitHub Actions schedules run in UTC by default, so a job scheduled for "9am" may fire at an unexpected local hour. Always confirm which zone your scheduler uses before relying on a specific time.

Verify Before You Deploy

Before trusting a cron expression in production, confirm it means what you think — ideally by reading back a plain-English description of when it will run. A schedule that looks right at a glance can hide an off-by-one in the day or hour that only surfaces days later.

Generated expressions are a good starting point, but verify them against your scheduler's exact dialect, since cron variants differ: Amazon EventBridge, for example, adds a sixth field for the year. Getting the schedule right up front saves the headache of a job that quietly ran at the wrong time for a week. The same check-before-use habit applies to the regex pattern guide and to an environment variable name generator.

Frequently asked questions

What are the fields in a cron expression?: Five fields: minute, hour, day of month, month, and day of week. The terse syntax of asterisks, commas, and slashes is what a generator helps you get right without memorizing it.
What is the most common cron mistake?: Setting both day-of-month and day-of-week — standard cron treats that as "either," not "both." Time zones are another trap, since classic cron runs in the server's zone and some platforms, such as GitHub Actions, default to UTC.
Should I verify a generated cron expression?: Yes — confirm it means what you intend, ideally via a plain-English readback, and check it against your scheduler's exact dialect. A small error can run a job at the wrong time for days unnoticed.

Sources

crontab(5) — cron — Debian Manpages — Debian
Events that trigger workflows - GitHub Docs — GitHub Docs
Setting a schedule pattern for scheduled rules (legacy) in Amazon EventBridge — Amazon Web Services