A cron expression is a string of 5 or 6 fields separated by spaces that defines a schedule for recurring tasks. Each field represents a time unit: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-7, where both 0 and 7 represent Sunday). The optional 6th field at the beginning represents seconds (0-59). Cron jobs are widely used in Unix/Linux systems, cloud platforms, and CI/CD pipelines for task automation such as backups, data syncing, and periodic reporting.

Asterisk (*) — matches all possible values (e.g., every minute).
Slash (/) — step values: */15 means every 15 units.
Comma (,) — lists multiple values: 1,3,5 matches 1, 3, and 5.
Hyphen (-) — defines ranges: 9-17 matches 9 through 17.
L — "Last" (e.g., L in day-of-month means the last day of the month).
W — nearest weekday to a given day.
Hash (#) — nth occurrence of a weekday: 2#3 = 3rd Tuesday.
Note: L, W, and # are advanced features not supported by all cron implementations.

The standard (POSIX) cron uses 5 fields: minute, hour, day-of-month, month, and day-of-week. This is the most common format supported by crontab, AWS CloudWatch Events, GitHub Actions, and most scheduling tools. The 6-field variant adds a leading seconds field, allowing sub-minute precision. This extended format is used by Quartz Scheduler (Java), Spring Boot's @Scheduled annotation, and some enterprise job schedulers. Our simulator supports both — use the toggle above the input to switch modes.

When both day-of-month (DOM) and day-of-week (DOW) fields are specified (neither is *), cron treats them with an OR relationship. The job triggers if either condition is met. For example, 0 0 15 * 1 runs at midnight on the 15th of every month AND every Monday — not just Mondays that fall on the 15th. If you need both conditions to apply simultaneously (AND logic), you'd need to handle that logic within the job script itself or use a wrapper condition.

Misconfigured cron expressions are a leading cause of missed backups, duplicate job runs, and production incidents. Testing helps you: verify timing — ensure the schedule matches your intent (e.g., "every weekday at 9 AM" vs "every day at 9 AM"); catch edge cases — such as February 30th or invalid ranges; understand frequency — avoid accidentally scheduling a job to run every second when you meant every hour; and validate across platforms — different systems (crontab, AWS, Kubernetes CronJob, Quartz) may interpret expressions slightly differently. Our visual simulator shows you exactly when jobs will fire, giving you confidence before deployment.

* * * * *	Every minute
*/15 * * * *	Every 15 minutes
0 * * * *	Every hour at minute 0
0 0 * * *	Daily at midnight
0 9 * * 1-5	Weekdays at 9:00 AM
0 0 * * 0	Every Sunday at midnight
0 0 1 * *	First day of every month
0 0 1 1 *	Yearly on January 1st
0 0 */2 * *	Every 2 days at midnight
0 8-18 * * *	Every hour from 8 AM to 6 PM

Standard cron runs based on the system's local timezone. During daylight saving time (DST) transitions: spring forward — jobs scheduled during the "skipped" hour (e.g., 2:30 AM) may not run at all; fall back — jobs scheduled during the repeated hour (e.g., 1:30 AM) may run twice. For mission-critical scheduling, consider using UTC-based cron or scheduling platforms that handle DST explicitly. Cloud schedulers like AWS EventBridge and Google Cloud Scheduler typically operate in UTC to avoid these issues.