Cron Expressions

Cron expressions describe recurring calendar times rather than the work performed at those times. A scheduler evaluates the expression and initiates a configured target, such as a data ingestion job, workflow, or metadata crawler. This separates scheduling policy from processing logic and makes recurring workloads easier to configure and operate. However, an expression alone does not define dependencies, retries, concurrency limits, or successful completion.

Traditional Unix cron uses five time fields: minute, hour, day of month, month, and day of week. Common operators include an asterisk for all allowed values, commas for multiple values, hyphens for ranges, and slashes for increments within a field. For example, the five-field expression 0 2 * * 1-5 selects 02:00 Monday through Friday in the scheduler’s configured time zone. An expression such as */15 * * * * selects quarter-hour boundaries; it does not mean 15 minutes after the previous execution finishes.

Cron dialects are not interchangeable. AWS scheduling interfaces commonly use a six-field form containing minute, hour, day of month, month, day of week, and year, wrapped in cron(...). For example, cron(0 2 ? * MON-FRI *) selects 02:00 on weekdays. The question mark leaves one day field unspecified; in EventBridge cron syntax, day of month and day of week cannot both be specified simultaneously. Other implementations may include a seconds field or interpret combinations of day fields differently. Validate expressions against the actual scheduler rather than assuming a generic online validator matches it.

Time zones are part of the schedule’s meaning. EventBridge Scheduler supports named time zones, whereas legacy EventBridge scheduled rules and AWS Glue schedules use UTC. Named-zone schedules can preserve a local business hour across daylight saving changes, but skipped or repeated local times require attention. EventBridge Scheduler skips a nonexistent local time during the spring transition and invokes only once for a repeated local time during the autumn transition. Do not assume every scheduler implements the same behavior.

In a data pipeline, a schedule might start ingestion at 01:00 each day and arrange a metadata refresh after ingestion succeeds. Scheduling the crawler independently for 01:15 is simpler, but it creates a timing assumption: a slow ingestion run could leave the crawler scanning incomplete data. Workflow dependencies or completion events are safer when downstream work requires upstream success. Similarly, an object-arrival event may be more appropriate than cron when processing should begin as soon as a file is available.

Apache Airflow adds workflow and data-interval semantics to cron scheduling. With its standard cron data-interval timetable, a daily run is normally scheduled after its data interval ends, so the logical date is not simply the task’s wall-clock start time. Catchup settings determine whether historical intervals are automatically scheduled. Configure start dates, time zones, catchup, and concurrent runs deliberately to avoid unexpected backlogs or overlapping ingestion.

Choose calendar-based cron when requirements specify times such as every weekday at 02:00. Choose a rate or interval schedule when the requirement is a regular elapsed-time cadence, while checking the scheduler’s anchoring behavior. Neither approach guarantees immediate execution or exactly-once processing. Use idempotent writes, appropriate execution permissions, retries, failure monitoring, and overlap controls. AWS Glue job and crawler schedules have five-minute minimum precision, illustrating why a valid expression must also satisfy the target service’s scheduling limits.