Cron Expression Generator — Build & Explain Cron Jobs

Cron syntax explained

A cron expression is a compact string of five fields separated by spaces. Each field controls when a scheduled task fires. From left to right the fields are: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, where 0 is Sunday).

An asterisk (*) matches every possible value for that field. A range is written with a hyphen, for example 1-5 in the day-of-week field means Monday through Friday. A step value uses a slash: */10 in the minute field fires every ten minutes. A list uses commas to specify discrete values, such as 1,15 in the day-of-month field to run on the 1st and 15th.

You can combine these operators within a single field. For instance, 0,30 9-17 * * 1-5 fires at the top and bottom of every hour during business hours on weekdays. Understanding these building blocks lets you express virtually any recurring schedule in a single line.

Common cron schedule examples

Below are schedules that cover the majority of real-world use cases:

• */5 * * * * -- every 5 minutes. Useful for health checks or queue polling.
• 0 0 * * * -- daily at midnight. A classic choice for log rotation or database backups.
• 0 9 * * 1-5 -- weekdays at 9 AM. Commonly used for morning report emails or CI pipeline triggers.
• 0 0 1 * * -- first day of every month at midnight. Ideal for billing cycles or monthly data aggregation.
• 0 3 * * 0 -- every Sunday at 3 AM. Often used for weekly maintenance windows such as index rebuilds or certificate renewal checks.

When crafting your own expressions, paste them into the generator above to instantly see the next execution times and confirm the schedule matches your intent.

Cron in different environments

The five-field cron syntax originated with the Unix crontab command, and it remains the default scheduler on Linux and macOS. You edit it with crontab -e and each line pairs an expression with the command to run.

systemd timers are the modern Linux alternative. Instead of a cron expression you write a OnCalendar= directive, but many administrators still prototype the schedule as a cron expression first and then convert it.

Kubernetes CronJobs use the same five-field syntax in their spec.schedule field. The controller creates a new Job resource on each trigger, so overlapping runs are possible if the previous one has not finished.

GitHub Actions accept a cron expression under on.schedule in workflow YAML files, always evaluated in UTC. AWS EventBridge (formerly CloudWatch Events) supports both cron and rate expressions; its cron variant adds a sixth field for the year and uses ? as a wildcard for either day field.

Common cron pitfalls

Even experienced developers run into these issues when setting up cron jobs:

• Timezone confusion. Classic crontab uses the system's local timezone, while Kubernetes CronJobs and GitHub Actions default to UTC. Always verify which timezone your scheduler uses before deploying.
• Overlapping runs. If a job takes longer than the interval between triggers, two instances can run simultaneously. Use a lock file, a flock wrapper, or the Kubernetes concurrencyPolicy: Forbid setting to prevent this.
• Day-of-month vs. day-of-week conflict. In standard cron, if both fields are set to non-wildcard values the job runs when either condition is true, not when both are true. This catches many people off guard.
• Missing PATH. Cron runs with a minimal environment. Commands that work in your interactive shell may fail because /usr/local/bin or language-specific paths are not in the default PATH. Set PATH explicitly at the top of your crontab or use absolute paths to binaries.
• Silent failures. By default cron mails output to the user's local mailbox, which is often unmonitored. Redirect output to a log file or send it to a centralized logging system so errors surface quickly.

Related tools on CodeBoxTools

If you work with scheduled jobs you may also find these tools useful:

• Epoch Converter -- convert between Unix timestamps and human-readable dates, helpful when debugging job execution logs that record times as epoch seconds.
• UUID Generator -- generate unique identifiers for job runs or correlation IDs in distributed task pipelines.
• Chmod Calculator -- calculate file permissions for cron scripts. A common setup step is ensuring the script is executable before adding it to the crontab.