What cron is and how it works
Cron is the standard Unix job scheduler. It runs commands or scripts at specified times without any manual intervention. A background daemon — crond — wakes up every minute, checks a table of scheduled entries called the crontab, and fires any job whose schedule matches the current time.
Each entry in a crontab is a single line: a timing expression followed by the command to run. The timing expression is five fields separated by spaces. Get those five fields right and your job runs exactly when you want it. Get one wrong — say, a missing asterisk or an off-by-one on the hour field — and it either never runs or fires every minute.
Cron expression syntax
The five fields are, in order: minute (0–59), hour (0–23), day-of-month (1–31), month (1–12), day-of-week (0–6, where 0 is Sunday). A field accepts four kinds of values: a specific number (5), a range (1-5), a step (*/15 means every 15 units), or a wildcard (* means every valid value). You can also combine these with commas: 1,3,5 means the 1st, 3rd, and 5th.
One common trap is the relationship between day-of-month and day-of-week. When both are set to something other than *, some cron implementations treat them as OR (the job runs if either condition is met), while others apply AND. If you need "the first Monday of the month," cron may not be the right tool — use a wrapper script that checks the date after launch.
Some cron implementations also accept shorthand aliases: @daily (midnight every day), @weekly (midnight Sunday), @hourly, and @reboot. These are readable but not universally supported — verify your host's cron version before depending on them.
Common cron patterns
A handful of patterns cover most real-world scheduling needs. */5 * * * * runs a job every five minutes — useful for polling queues or checking API status. 0 9 * * 1-5 fires at 9:00 AM Monday through Friday, the standard pattern for business-hours reports. 0 0 1 * * runs at midnight on the first of every month, common for billing cycles and log rotation.
0 */6 * * * runs every six hours (midnight, 6 AM, noon, 6 PM). 30 23 * * 0 runs at 11:30 PM on Sundays — useful for weekly maintenance windows that avoid peak traffic. For jobs that should run once at a specific date, cron is the wrong tool; use at or a one-time scheduled task instead.
How to build a cron expression
Start from the question: when exactly should this run? Write it in plain English first — "every day at 2:30 AM" — then translate field by field. Minute = 30, hour = 2, day-of-month = *, month = *, day-of-week = *. The result: 30 2 * * *. Open the cron expression builder, enter those values, and confirm the plain-English description matches your intent before copying the expression.
When building expressions for specific days, remember that day-of-week counts from 0 (Sunday) to 6 (Saturday). Some implementations also accept 7 as Sunday — check your platform's documentation. For timezone-sensitive jobs, keep in mind that cron uses the system's local timezone. A server in UTC will execute 0 9 * * * at 9 AM UTC, which is not 9 AM in New York or Tel Aviv. Use a timezone converter to confirm the UTC equivalent of your intended local time before setting the schedule.
Testing cron expressions before deploying
Never deploy a cron expression untested. A single misplaced asterisk can trigger a resource-intensive job every minute instead of once a day, saturating a database or sending thousands of emails. The cron expression builder shows the next 5–10 scheduled run times for any expression — read through them and confirm they match your expectation.
For jobs that depend on timing across timezones, cross-reference the scheduled UTC time with a Unix timestamp converter to verify the epoch offsets. After deploying, check your server logs for the first two or three expected runs. A job that doesn't appear in the logs at the expected time either never fired (syntax error, permissions issue) or ran at the wrong minute (field error). Catch it within the first hour, not after a month of missed backups.
Getting the schedule right
Cron expressions look deceptively simple — five numbers and some asterisks — but small mistakes have real consequences. An incorrectly scheduled cleanup job deletes files at the wrong time. A misconfigured report job runs 288 times a day instead of once. Taking 30 seconds to verify the expression against its next run times before saving it to a crontab is the only reliable way to avoid those failures.
The cron expression builder generates and validates expressions interactively, showing both the syntax and the upcoming schedule so you can confirm both before deploying. Pair it with the timezone converter if your job needs to run at a specific local time on a UTC server.