Cron Debugging Workflow

Shipping a cron line without verification is how teams learn their backup runs at noon instead of midnight. Treat schedules like code: parse, explain, preview.

Step 1: Normalize the line

• Five fields only (unless your platform documents six)
• No extra spaces; comments stripped (# backup job on its own line in crontab, not inside fields)
• Confirm you are not mixing Quartz ? syntax with Unix cron

Paste the expression into a parser and read the field-by-field breakdown.

Step 2: Read the human description

A good description answers:

• Which minutes and hours fire?
• Are day-of-month and day-of-week both restricted—and does OR semantics apply?
• Is this “every weekday morning” or something stranger?

If the English (or localized) summary does not match intent, fix fields before deploying.

Step 3: Preview next run times

Generate at least three to five upcoming instants in:

• The platform’s execution timezone
• UTC (for correlating with logs and Actions)

Compare against a calendar—especially around month boundaries, DST transitions, and short months.

Step 4: Cross-check platform docs

Question	Action
GitHub Actions?	Assume UTC
K8s CronJob?	Set timeZone explicitly
Linux crontab?	Know server timedatectl
Six-field engine?	Translate, do not copy blindly

Common mistakes checklist

Mistake	Symptom
Sunday as 7 vs 0 confusion	Off-by-one weekday
DOM and DOW both set expecting AND	Extra runs
*/60 in minute field	Invalid or empty schedule
Local 9am written for UTC Actions	Job runs at wrong wall time
Long job + short interval	Overlapping executions

Step 5: Document in the runbook

Record expression, timezone, platform, owner, and expected duration. Link to monitoring that proves the last run succeeded.

Key takeaway

Parse → describe → preview → document. If any step disagrees with expectations, stop. Cron bugs are silent until finance asks why reports ran twice.