Cron Expressions Explained: 5 vs 6 Fields and Pitfalls

Two mainstream formats

The Linux/Unix standard uses 5 fields: minute hour day month weekday. Quartz (the Java/Spring world) uses 6 fields with an extra "seconds" in front. Confirm which one your platform expects first, otherwise the whole expression is shifted.

Special characters at a glance

• * any value;
• ? unspecified (day or weekday only);
• , list: 0 0 1,15 * * on the 1st and 15th;
• - range: 0 9-18 * * * from 9:00 to 18:59;
• / step: */5 every 5 units.

The two most common pitfalls

1. Day and weekday both set: most implementations combine them with OR, the 1st OR Monday triggers, which is counter-intuitive. For "only the 1st", set weekday to ?.
2. Timezone: Cron runs in the server timezone. A UTC server while you are in UTC+8 means local 9:00 is 0 1 * * *.

Debugging tip

Instead of deploying repeatedly, compute the next few execution times with a parser and check them against your expectation, reversed fields show up in seconds.

Ready-to-use expressions

Job did not run? Check in this order

1. Timezone: containers default to UTC, local 09:00 is 0 1 * * *;
2. The daemon: cron is not running, or the crontab vanished after a restart;
3. Field count: the platform expects 6 fields (Quartz) and you supplied 5, or the reverse;
4. A stray second field: * * * * * * fires every second and can hammer the machine;
5. No logging: append >> /var/log/job.log 2>&1 to confirm the job is triggered at all.

A minimal pre-deploy check

Compute the next five execution times with a parser and compare them to your expectation, far faster than watching logs after deploy. This matters most across timezones: the same expression differs by 8 hours between UTC and UTC+8 servers.

A minimal pre-launch checklist

1. Confirm the next 3–5 run times with a parser;
2. Confirm the timezone (containers usually default to UTC) matches business time;
3. Confirm the job is idempotent: running it twice causes no side effects, so replay is safe;
4. Confirm logs are persisted and alerting works, so a failure surfaces immediately rather than through user complaints.

Try them: Cron parser, Timestamp converter