Cron Expression Generator

What Is a Cron Expression?

A cron expression is a compact string that defines a schedule for running automated tasks on Unix/Linux systems. The cron daemon reads this expression and triggers commands at the exact configured times. A standard cron expression consists of 5 fields separated by spaces, representing: minute, hour, day of month, month, and day of week.

For example, 30 9 * * 1-5 means: run at 9:30 AM every Monday through Friday. The expression 0 0 1 * * runs at midnight on the first day of every month. The syntax is concise yet powerful, allowing you to configure complex schedules in a single line.

Cron is used extensively in system administration, DevOps, and software development. From nightly database backups to periodic email sends to temporary file cleanup, cron is an indispensable tool on every Linux server.

Cron Syntax Explained Field by Field

Every 5-field cron expression has a fixed structure. Understanding each field helps you write and read expressions accurately:

Field 1: Minute (0-59)

Determines which minute of the hour the task runs. A value of 0 means the top of the hour, 30 means the 30th minute, and */5 means every 5 minutes. You can combine values: 0,15,30,45 runs 4 times per hour at quarter-hour intervals.

Field 2: Hour (0-23)

Uses 24-hour format. 0 is midnight, 12 is noon, 9-17 covers business hours from 9 AM to 5 PM. Combined with the minute field: 30 9 means 9:30 AM.

Field 3: Day of Month (1-31)

Specifies which day of the month. 1 is the first day, 1,15 means the 1st and 15th. Note that if you specify day 31 but the month only has 30 days, the task will not run that month.

Field 4: Month (1-12)

Defines which months the task runs. 1 is January, */3 means every 3 months (January, April, July, October). Useful for quarterly reports or seasonal maintenance tasks.

Field 5: Day of Week (0-6)

0 or 7 is Sunday, 1 is Monday, 5 is Friday. The expression 1-5 means Monday through Friday (business days). 0,6 means weekends only.

Common Cron Schedules and Examples

Here are the most frequently used cron expressions in real-world scenarios:

• * * * * * — Every minute. Commonly used for monitoring systems or health checks.
• */5 * * * * — Every 5 minutes. Popular for cache refreshes or queue checks.
• 0 * * * * — Top of every hour. Ideal for data synchronization or logging statistics.
• 0 0 * * * — Daily at midnight. Commonly used for database backups, log rotation, or daily report generation.
• 0 9 * * 1 — Every Monday at 9 AM. Perfect for sending weekly email reports or team reminders.
• 0 0 1 * * — First of every month at midnight. Used for recurring billing, monthly data aggregation.
• 30 8 * * 1-5 — 8:30 AM on weekdays. Great for morning notifications or daily status reports.
• 0 */6 * * * — Every 6 hours. Balances update frequency against system load.

Cron in Different Platforms

While cron syntax originated in Unix/Linux, it is now widely used across many platforms with some variations:

Linux (crontab)

The traditional cron system. Use crontab -e to edit schedules. Each line consists of a 5-field expression followed by the command. Example: 0 2 * * * /usr/bin/backup.sh. Check your entries with crontab -l.

AWS CloudWatch Events / EventBridge

AWS uses 6-field cron expressions (adding a seconds or year field depending on the service). The syntax differs slightly: cron(0 9 * * ? *) uses ? instead of * for the day/weekday field. This is a common mistake when migrating from Linux to AWS.

GitHub Actions

GitHub Actions supports standard 5-field cron in the schedule trigger. Important note: run times are based on UTC timezone, and GitHub does not guarantee exact execution — there may be delays of several minutes during high-load periods. Use the JSON Formatter to validate your workflow YAML files.

Kubernetes CronJob

Kubernetes uses standard 5-field cron syntax in CronJob manifests. It supports additional policies for long-running tasks: concurrencyPolicy: Forbid prevents overlapping runs.

Debugging Cron Jobs — Common Mistakes

Cron is simple in concept but has many subtle pitfalls. Here are the most common mistakes and how to fix them:

• Wrong timezone: The server cron daemon typically uses UTC. If you are in Vietnam (UTC+7), 0 9 * * * will run at 4 PM Vietnam time, not 9 AM. Check server timezone with timedatectl or date.
• Non-absolute paths: In cron environments, the PATH variable is very limited. Always use absolute paths for commands: /usr/bin/python3 instead of python3. Use the Base64 Encoder if you need to encode credentials for cron scripts.
• Missing environment variables: Cron does not load shell profiles (.bashrc, .zshrc). If your script needs environment variables, define them directly in the crontab or source the profile file in your script.
• File permissions: Scripts must be executable (chmod +x script.sh). Cron runs with the permissions of the user who owns the crontab entry.
• Not checking logs: Always redirect output for debugging: 0 * * * * /script.sh >> /var/log/myscript.log 2>&1. Without logs, you have no way to diagnose why a script is not running.
• Day vs weekday confusion: When both the day-of-month and day-of-week fields are set to non-asterisk values, cron runs when EITHER condition matches (OR logic), not when both match (AND). This is the most confusing behavior for beginners. Use the Regex Tester to validate log patterns from cron output.