Cron Expressions Explained: Fields, Time Zones, and Deployment Risks

Classic cron expressions use five fields: minute, hour, day of month, month, and day of week. Some systems add seconds or year fields, while others use named macros such as @daily. This variation is the first source of mistakes. An expression copied from one scheduler may not mean the same thing in another. Always confirm the field count and dialect before moving a schedule between Linux cron, cloud schedulers, CI systems, and application libraries.

An asterisk means every allowed value in a field. A range limits values. A step such as */15 means every fifteen units within that field. These pieces combine quickly. The expression */15 * * * * runs every fifteen minutes, while 15 * * * * runs once each hour at minute fifteen. Reading the expression out loud as concrete times is often safer than relying on memory of symbols.

Cron dialects differ in how they combine day-of-month and day-of-week when both are restricted. Some treat the schedule as matching either field, while some libraries document different behavior. This matters for expressions like "run on the first day of the month and Monday." If the business rule is important, preview multiple months and check the scheduler documentation. A natural-language label is not enough.

A cron expression without a timezone is incomplete operational information. It might run in server local time, container time, UTC, project settings, or scheduler-specific configuration. Daylight saving time adds another wrinkle: local times can be skipped or repeated. For jobs that affect billing, emails, maintenance windows, or customer-visible updates, store the intended timezone beside the expression and preview future runs across a daylight-saving boundary.

A perfect cron expression does not make a job safe. Scheduled jobs can run late, overlap with previous runs, retry after failures, or be triggered manually during incidents. If a job sends emails, charges accounts, deletes data, or updates state, it should be idempotent or protected by locks and clear retry rules. Cron controls when a job starts; the application still controls what happens if the world is not in the expected state.

The best schedule configuration includes the expression, the human intention, and the timezone. For example: "Run at 09:00 Europe/Berlin every business day." This comment helps reviewers detect mismatches. It also helps the next person decide whether a change should alter the cron expression, the timezone setting, or the job logic. Cron strings are too compact to be their own documentation.

Before deploying a schedule, preview at least the next ten run times. Check weekdays, month boundaries, daylight-saving transitions, and the exact environment timezone. For critical jobs, test in a non-production environment with harmless output. Add monitoring that confirms the job ran and that it produced the expected result. The goal is not only to make cron parse; it is to make the operational behavior boring.