Cron Expression Generator

What is cron?

Cron is the standard job scheduler found in Unix and Linux operating systems. It executes commands or scripts at specified times and intervals, making it essential for system administration, DevOps automation, and backend application scheduling. The name comes from the Greek word chronos, meaning time.

A cron expression is a compact string of five fields that defines when a job should run. Each field specifies a time component — minute, hour, day of month, month, and day of week. Together, these five fields can express schedules ranging from "every minute" to "once a year on a specific date."

Cron syntax explained

Each of the five fields accepts specific values and special characters. An asterisk (*) means "every possible value." A number sets a specific value. A hyphen (1-5) defines a range. A comma (1,3,5) creates a list. A slash (*/5) sets a step interval. Combining these operators lets you build virtually any schedule.

Field reference

• Minute (0–59): The minute of the hour when the job runs.
• Hour (0–23): The hour of the day in 24-hour format. 0 is midnight, 12 is noon.
• Day of month (1–31): The calendar day. Not every month has 31 days — cron skips invalid dates automatically.
• Month (1–12): The calendar month. 1 is January, 12 is December.
• Day of week (0–6): The weekday. 0 is Sunday, 6 is Saturday. Some systems also accept 7 for Sunday.

Common cron expressions

• 0 0 * * * — 0 0 * * * — Every day at midnight.
• 0 9 * * 1-5 — 0 9 * * 1-5 — Weekdays at 9:00 AM.
• 0 0 1 * * — 0 0 1 * * — First day of every month at midnight.
• */15 * * * * — */15 * * * * — Every 15 minutes.
• 0 */4 * * * — 0 */4 * * * — Every 4 hours on the hour.

Common cron mistakes

The most frequent mistake is putting fields in the wrong order. Cron always reads minute first, then hour — so "0 9" means 9:00 AM, not minute 9. Another pitfall is forgetting that the server's timezone determines when cron runs. If your server is in UTC but you expect local time, jobs will fire at the wrong hour.

Avoid scheduling resource-heavy jobs at exactly midnight (0 0 * * *) because many other cron jobs run at the same time. Stagger your jobs by a few minutes to prevent load spikes. Also beware of jobs that take longer to complete than their interval — if a job runs every minute but takes 3 minutes, you will have overlapping instances.

Best practices

Always redirect cron output to a log file (>> /var/log/myjob.log 2>&1) so you can troubleshoot failures. Use absolute paths for commands and scripts because cron runs with a minimal PATH environment. Test your expression with a tool like this one before deploying to production.

For complex scheduling needs, consider cron alternatives like systemd timers (Linux), Celery Beat (Python), or cloud schedulers (AWS EventBridge, Google Cloud Scheduler). These offer features like retry logic, monitoring dashboards, and distributed execution that standard cron lacks.

Frequently asked questions

Can cron run a job every 30 seconds?

No. Cron's minimum resolution is one minute. To run a task every 30 seconds, schedule it every minute and add a 30-second sleep before a second execution within the same script. Alternatively, use a systemd timer or a language-specific scheduler for sub-minute intervals.

Where is the crontab file located?

User crontabs are stored in /var/spool/cron/ (Red Hat/CentOS) or /var/spool/cron/crontabs/ (Debian/Ubuntu). Edit yours with "crontab -e" instead of modifying files directly. The system crontab is at /etc/crontab and additional jobs can be placed in /etc/cron.d/.