Cron Expression Generator

Cron expressions are the universal scheduling language of server administration, but their compact syntax is notoriously easy to get wrong.

A misplaced asterisk can mean the difference between running a job once a day and running it every minute. This cron expression generator lets you build cron schedules visually, see a plain-English description of the resulting schedule, and preview the next several execution times before deploying anything.

The tool supports the standard five-field cron format used by Unix crontab, Linux systemd timers, and most job schedulers. Select the minute, hour, day of month, month, and day of week using dropdowns and checkboxes, and the tool assembles the expression and explains exactly what it means. You can also paste an existing expression to decode it and verify it does what you think it does.

Whether you are scheduling database backups, setting up log rotation, configuring CI/CD pipeline triggers, or automating any recurring task, this generator removes the guesswork from cron syntax. Build the schedule, verify the next run times, and copy the expression into your crontab or configuration file with confidence.

What Is a Cron Expression?

A cron expression is a string of fields separated by spaces that defines a recurring schedule. The name comes from the Unix cron daemon, a time-based job scheduler that has been part of Unix-like operating systems since the 1970s. Despite its age, cron remains the most widely used scheduling mechanism in server administration, DevOps, and application development.

The standard cron expression has five fields:

┌───────────── minute (0-59)
│ ┌───────────── hour (0-23)
│ │ ┌───────────── day of month (1-31)
│ │ │ ┌───────────── month (1-12)
│ │ │ │ ┌───────────── day of week (0-7, where 0 and 7 are Sunday)
│ │ │ │ │
* * * * *

Each field accepts specific values, ranges, lists, and special characters that combine to define precisely when a job should execute. The power of cron lies in its ability to express complex schedules in a compact format, but that same compactness makes expressions error-prone when written by hand.

Cron Field Values and Special Characters

Every field in a cron expression supports a common set of values and operators.

Asterisk () means "every possible value" for that field. runs every minute of every hour of every day. It is the most common source of accidental high-frequency execution.

Comma (,) separates a list of specific values. 1,15 runs at minute 1 and minute 15 of every hour. Lists let you specify multiple discrete times within a single field.

Hyphen (-) defines a range of values. 9-17 in the hour field means every hour from 9 AM to 5 PM. Ranges are inclusive on both ends.

Slash (/) defines step values. /5 * in the minute field means every 5 minutes (0, 5, 10, 15, …). You can combine slashes with ranges: 10-30/5 means every 5 minutes starting at minute 10 through minute 30 (10, 15, 20, 25, 30).

Day of week values accept both numbers (0-7, where both 0 and 7 represent Sunday) and three-letter abbreviations (SUN, MON, TUE, WED, THU, FRI, SAT) in most implementations. Month values similarly accept numbers (1-12) or abbreviations (JAN through DEC).

Understanding these operators is essential for building correct schedules. A common mistake is writing 0 /2 expecting it to run every 2 hours starting at the top of the hour, which it does, but starting from hour 0 (midnight), not from the current time. Cron schedules are absolute, not relative.

Common Cron Schedule Examples

Learning cron is fastest through examples. Here are the schedules developers use most frequently.

Every minute: * — This is almost never what you want in production. It is useful for testing that cron is working but will overwhelm most jobs if left running.

Every 5 minutes: /5 * — A popular interval for health checks, metric collection, and queue processing.

Every hour at minute 0: 0 — Runs at the top of every hour. Common for hourly reports and data syncs.

Every day at midnight: 0 0 * — The classic daily job schedule. Database backups, log rotation, and daily report generation typically run here.

Every day at 2:30 AM: 30 2 * — Running maintenance jobs in the early morning avoids peak traffic. The 2-3 AM window is traditional for this reason, though be aware of daylight saving time transitions in that window.

Every weekday at 9 AM: 0 9 1-5 — Business-hours jobs like sending daily standup reminders or generating weekday reports.

Every Monday at 8 AM: 0 8 1 — Weekly jobs like sending status reports or triggering weekly builds.

First day of every month at midnight: 0 0 1 — Monthly billing runs, certificate renewal checks, and monthly data aggregation.

Every 15 minutes during business hours on weekdays: /15 9-17 * 1-5 — Runs at :00, :15, :30, and :45 of every hour from 9 AM to 5 PM, Monday through Friday.

How Cron Handles Day-of-Month and Day-of-Week Together

One of the most confusing aspects of cron is how it handles the day-of-month and day-of-week fields when both are specified. In standard Unix cron, if both fields are set to non-asterisk values, the job runs when either condition is met (OR logic), not when both are met (AND logic).

For example, 0 9 15 * 1 does not mean "run at 9 AM on the 15th if it falls on a Monday." It means "run at 9 AM on every 15th of the month AND on every Monday." This is a common source of unexpected behavior.

Some cron implementations (notably the Quartz scheduler used in Java applications and the extended cron formats used by some cloud services) handle this differently, using AND logic instead. Always check the documentation for your specific cron implementation when combining day-of-month and day-of-week conditions.

If you need AND logic in standard cron, the typical workaround is to use a broader cron schedule and add a conditional check within your script that exits early if the conditions are not met.

Cron in Different Environments

While the five-field format is universal, cron implementations vary across platforms and services.

Unix/Linux crontab is the original implementation. Edit it with crontab -e and it follows the standard five-field format. System-wide cron jobs in /etc/crontab and /etc/cron.d/ add a sixth field for the user account that should run the job.

Systemd timers are the modern Linux alternative to cron. They use a different configuration format (OnCalendar syntax in .timer unit files) but serve the same purpose. Systemd timers offer features cron lacks, including dependency management, logging integration, and resource controls.

AWS CloudWatch Events and EventBridge use a six-field cron format that adds a seconds field at the beginning and a year field at the end. AWS cron also uses ? (no specific value) as a required character in either the day-of-month or day-of-week field, and it uses AND logic when both day fields are specified.

GitHub Actions uses the standard five-field format in workflow YAML files under the schedule trigger. Schedules run in UTC and are subject to delays during periods of high load on GitHub’s infrastructure.

Kubernetes CronJobs use the standard five-field format and schedule pods to run on the defined schedule. Kubernetes adds its own considerations around timezone handling (UTC by default, with timezone support added in v1.25+), concurrency policies, and missed job handling.

Google Cloud Scheduler and Azure Functions use the standard five-field format with some extensions. Cloud Scheduler supports timezone-aware scheduling natively.

When building expressions with this generator, the output follows the standard five-field format compatible with all of these environments. Consult your platform’s documentation for any extensions or restrictions that apply.

Timezone Considerations

Cron jobs run according to the system clock of the machine (or service) executing them. In most server environments, the system clock is set to UTC. This means 0 9 * runs at 9 AM UTC, not 9 AM in your local timezone.

Failing to account for timezone differences is one of the most common cron mistakes, especially for teams distributed across multiple time zones. If you need a job to run at 9 AM Eastern Time, you need to convert that to UTC (14:00 UTC during Eastern Standard Time, 13:00 UTC during Eastern Daylight Time) and set the cron expression accordingly.

Daylight saving time transitions create an additional complication. Jobs scheduled to run between 2:00 AM and 3:00 AM local time may run twice (during the fall-back transition) or not at all (during the spring-forward transition), depending on how the cron implementation handles the clock change. If absolute consistency matters, schedule jobs in UTC.

Use our Unix Timestamp Converter to verify timezone conversions and our Date Calculator to plan around daylight saving transitions.

Debugging and Monitoring Cron Jobs

A cron expression might be syntactically correct but still fail in practice. Here are the most common issues and how to address them.

Job runs but produces no output. Cron jobs run in a minimal environment with a restricted PATH. Commands that work in your interactive shell may fail in cron because the necessary directories are not in the cron PATH. Always use absolute paths for commands (e.g., /usr/bin/python3 instead of python3) and set environment variables explicitly at the top of your crontab.

Job does not run at all. Check that the cron daemon is running (systemctl status cron or service cron status). Verify the expression syntax by pasting it into this generator. Check the system mail for cron error messages (mail command or /var/mail/username). Ensure the crontab file has proper line endings (LF, not CRLF) and ends with a newline.

Job runs at unexpected times. Double-check the timezone configuration. Verify your understanding of the expression by pasting it into this generator and reviewing the plain-English description and next run times. Remember the OR logic for combined day-of-month and day-of-week fields.

Job runs too frequently. An asterisk in the minute field means every minute. This is the most common accidental misconfiguration. If your job should run once an hour, the minute field needs a specific value (like 0), not an asterisk.

Overlapping executions. If a job takes longer to complete than the interval between scheduled runs, multiple instances can stack up. Use a lock file mechanism (flock on Linux), a process-level mutex, or your scheduler’s built-in concurrency controls (like Kubernetes CronJob’s concurrencyPolicy: Forbid) to prevent overlapping runs.

Frequently Asked Questions

What does the asterisk mean in a cron expression?

The asterisk () means "every possible value" for that field. An asterisk in the minute field means every minute, in the hour field means every hour, and so on. It is the wildcard character. The expression means "run every minute of every hour of every day."

How do I schedule a cron job to run every 5 minutes?

Use /5 *. The /5 after the asterisk in the minute field means "every 5th value starting from 0." This runs at minutes 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55 of every hour.

What timezone do cron jobs use?

By default, cron jobs run according to the system clock, which is UTC on most servers. If you need a job to run at a specific local time, convert that time to UTC and set the cron expression accordingly. Some platforms (like Google Cloud Scheduler) support timezone-aware scheduling natively.

Can I run a cron job on the last day of every month?

Standard cron does not have a "last day of month" keyword. The workaround is to schedule the job for days 28-31 and add a check in your script that verifies today is actually the last day of the month before proceeding. Some extended cron implementations (like Quartz) support an "L" modifier for this purpose.

What is the difference between 5-field and 6-field cron?

Standard Unix cron uses 5 fields: minute, hour, day-of-month, month, day-of-week. Some systems add a sixth field. In the system-wide crontab, the sixth field specifies the user. In tools like the Quartz scheduler and AWS EventBridge, a seconds field is added at the beginning. Always check which format your platform expects.

How do I prevent overlapping cron job executions?

Use a lock file mechanism. On Linux, wrap your command with flock: flock -n /tmp/myjob.lock /path/to/script.sh. If the lock file is already held (meaning the previous run is still going), flock will skip the execution. Kubernetes CronJobs offer a concurrencyPolicy field for the same purpose.

Does cron support seconds?

Standard Unix cron does not support seconds. The smallest unit is one minute. If you need sub-minute scheduling, use a loop within a script, a dedicated task scheduler like systemd timers (which support microsecond precision), or an application-level scheduler that supports seconds.

Data accurate as of: March 2026