A cron expression generator takes the guesswork out of scheduling background jobs. Cron syntax — five fields separated by spaces — is compact by design, which makes it fast to write once you know it and easy to get subtly wrong when you don't. This tool lets you pick a schedule from plain-English presets or paste in an expression someone else wrote and see, field by field, what it actually does before it runs in production.
It's part of a small set of free developer utilities Arb Digital publishes alongside our client work — the same instinct for clear, dependable tooling that goes into the websites and automation we build for clients.
What This Cron Expression Generator Does
The tool works in two directions. Build mode turns simple choices — "daily at 9am," "weekly on Monday," "monthly on the 1st" — into the correct five-field cron string, so you never have to remember whether day-of-week is zero-indexed or which field comes first. Explain mode does the reverse: paste any standard cron expression and the tool parses each field and produces a plain-English sentence describing exactly when the job fires, catching a wrong field before it costs you a missed deployment or a job that runs every minute instead of every hour.
Both modes update instantly as you type or change a dropdown, so you can sanity-check a schedule in seconds rather than mentally tracing five space-separated fields.
How to Use It
- Pick a preset if your schedule is common — every minute, hourly, daily, weekly, or monthly — and the hour/minute/day fields will fill in automatically.
- Adjust the hour, minute, weekday, or day-of-month fields to match your exact schedule.
- Copy the generated expression straight into your crontab, GitHub Actions workflow, Laravel scheduler, or cloud scheduler config.
- Or paste an expression you already have into the explain field to confirm it does what you think it does before deploying it.
- Double-check your timezone. The generator produces the expression only — it doesn't know your server's configured timezone, so confirm that separately.
The Five Fields of a Cron Expression
A standard cron expression has five space-separated fields, in this exact order: minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–7, where both 0 and 7 mean Sunday). An asterisk in any field means "every value" for that field. So `0 9 * * 1` means minute 0, hour 9, any day of month, any month, and weekday 1 — Monday — which reads as "every Monday at 9:00 AM." The definitive reference for this syntax is the crontab man page, documented in POSIX and mirrored in most Unix distributions' own `man 5 crontab`, along with community references like crontab.guru, widely used for interactively verifying expressions.
Beyond the asterisk, cron supports a few extra operators worth knowing: a comma (`1,15`) lists specific values, a hyphen (`1-5`) defines a range, and a slash (`*/15`) defines a step — `*/15` in the minute field means "every 15 minutes." Combining these lets you express schedules like "every weekday at 6pm" (`0 18 * * 1-5`) or "every 10 minutes during business hours" (`*/10 9-17 * * *`) without needing multiple crontab lines.
Where Cron Expressions Show Up in Real Projects
Cron syntax isn't limited to the classic Unix `crontab -e`. It's the same five-field format (sometimes six, with seconds prepended) used by Laravel's task scheduler, Django-cron, most CI platforms' scheduled workflow triggers, AWS EventBridge scheduled rules, Google Cloud Scheduler, and Kubernetes CronJobs. Learning the syntax once means you can schedule a database backup on a bare-metal server and a serverless function in the cloud with the exact same mental model.
Because so many systems share this format, a mistake in a cron expression tends to be silent — the job either doesn't run when expected, or it runs far more often than intended, sometimes hammering an API or database until someone notices. Verifying an expression before it goes live, rather than after a job misfires in production, is the entire reason a tool like this exists.
Reading Day-of-Week and Day-of-Month Together
One subtlety that trips people up: when both day-of-month and day-of-week are set to something other than `*`, most cron implementations treat them as an OR, not an AND — the job runs if either condition is true. So `0 0 1 * 1` runs at midnight on the 1st of every month AND every Monday, not only on Mondays that happen to fall on the 1st. If you only want one condition to matter, leave the other field as `*`.
- Use `*` in day-of-month when you're scheduling by weekday only.
- Use `*` in day-of-week when you're scheduling by a specific calendar date only.
- Avoid setting both to specific values unless you genuinely want the OR behavior.
Arb Digital builds the backend automation, integrations, and websites that these scheduled jobs run inside. If your project needs more than a script, let's talk.
Our Services All Free ToolsCommon Mistakes to Avoid
- Confusing minute and hour field order — cron always lists minute first, hour second, unlike how people naturally say a time.
- Assuming `0` and `7` are different weekdays — both represent Sunday in standard cron.
- Forgetting that some job runners use six fields (seconds first), which shifts every field one position to the right.
- Not accounting for server timezone — a job set for "9am" can run at the wrong local time if the server's clock is UTC.
- Leaving both day-of-month and day-of-week restricted, not realizing they combine with OR logic rather than AND.
Related Free Tools From Arb Digital
Pair this with the Open Graph Tag Generator for your deployed pages, the String to Slug Converter for clean URLs, and the JSON to XML Converter for data pipeline work. Browse the full free online tools hub for more.
Reading the Five Fields at a Glance
A standard cron expression is five fields separated by spaces, and once you can read them left to right the whole thing stops looking like hieroglyphics: minute (0–59), hour (0–23), day-of-month (1–31), month (1–12), and day-of-week (0–6, Sunday=0). An asterisk means "every value" for that field. So 30 2 * * * reads as "at minute 30 of hour 2, every day, every month, every weekday" — that is 2:30 AM daily. The special characters build on that: */15 means "every 15", a comma lists values (1,15), and a hyphen gives a range (9-17). Master those four and you can decode almost any schedule.
The field that trips everyone is the day-of-week / day-of-month interaction. When both are restricted, most cron implementations treat them as an OR, not an AND: 0 0 1 * 1 runs on the 1st of the month and every Monday, not "the 1st only if it's a Monday". If you want a job to run on, say, the first Monday of the month, cron alone cannot express it cleanly — you script the day check inside the job itself. Knowing this quirk up front saves the classic bug where a "monthly" task fires far more often than intended.
Timezones, Overlaps and the Gotchas That Bite
Cron runs in the server's local timezone unless told otherwise, and that single fact causes a huge share of "my job ran at the wrong time" tickets. A schedule set for 9 AM on a UTC server fires at what feels like the middle of the night to a team in another region, and daylight-saving transitions can make a job skip or repeat around the clock change. The fix is to standardise on UTC for anything critical, or use a scheduler that lets you pin an explicit timezone, and to document which one an expression assumes so the next person is not guessing.
The other quiet danger is overlap. Cron starts your job on schedule whether or not the previous run has finished, so a task set to run every minute that occasionally takes ninety seconds will pile up, spawning overlapping processes that fight over the same database rows or files. Guard against it with a lock file or a "skip if already running" check, and prefer generous intervals for anything that touches shared state. Finally, always test with a tool like the one above and a plain-English readback before trusting a schedule — a single misplaced field can turn "monthly cleanup" into "every minute forever".
Where Cron Runs — and the Modern Alternatives
Classic cron lives in a crontab file on a Unix-like server, edited with crontab -e and listed with crontab -l, with each user having their own table plus a system-wide /etc/crontab. That model is bulletproof for a single always-on machine, but it shows its age in cloud and container environments where servers are ephemeral and may not even be running when a job is due. A container that scales to zero overnight will silently miss its 3 AM cron, which is a nasty surprise the first time a nightly report simply never arrives.
That is why the cron syntax has long outlived the original cron daemon. The same five-field expression you build above is understood by Kubernetes CronJobs, GitHub Actions schedules, cloud schedulers like AWS EventBridge and Google Cloud Scheduler, CI pipelines, and countless application job libraries. Learning to read and write the expression is therefore a transferable skill: the field meanings, the asterisks, the ranges and steps all carry over unchanged, even though the thing actually watching the clock has moved from a lone server process to a managed, highly-available service. Write the expression once here, and it drops into almost any modern scheduler.
Frequently Asked Questions
Minute, hour, day of month, month, and day of week, in that order, each separated by a single space.
An asterisk means "every value is allowed" for that field, so it places no restriction on when the job can run.
Yes, most cron implementations accept both 0 and 7 as Sunday, with Monday as 1 through Saturday as 6.
Standard cron treats them as an OR condition — the job runs if either the date or the weekday matches, not only when both match.
By default, yes, unless the scheduler is explicitly configured with a timezone setting like CRON_TZ, so always verify the server's clock before relying on exact timing.
Yes, it runs entirely in your browser with no sign-up, no limits, and no data sent to a server.
