Guide

Why the same cron expression can behave differently

Cron has dialects. Field count, special symbols, weekday numbering, and timezone assumptions vary between environments.

A valid expression can still be wrong for your platform

Linux crontab commonly uses five fields. Other schedulers add seconds or even a year field. Copying an expression without checking the target dialect can shift the meaning completely.

Timezone is the classic “it runs, just not when I expected” problem

Many hosted systems schedule in UTC unless told otherwise. The expression can be syntactically perfect and still fire nine hours away from the time you had in mind.

Special symbols are not portable

`L`, `?`, and `#` exist in some cron dialects and not others. If an expression looks unusually clever, check the scheduler documentation before relying on it.

Look at the next few run times

Concrete timestamps are much easier to verify than a compact expression. Generate the next five runs, then test a small job in the actual environment.

If you only check three things

Count the fields. Check the scheduler’s timezone. Check the scheduler’s own cron documentation. Then generate concrete upcoming run times.

Those four steps solve a large share of “the expression looks right” problems without memorizing every cron dialect.