Cron Job Debugging Checklist

AIGClub Team

When a job misses, repeats, or runs at the wrong time, do not edit only the expression. Timezone, permissions, environment, and scheduler differences often cause the failure.

To debug cron, first confirm the target scheduler dialect and field count, then preview future run times. Next check timezone, day-of-month versus weekday rules, deployment environment, job permissions, recent execution logs, and failed responses. A browser-local parser can check the expression, but it cannot prove production execution.

Check the expression with fixed evidence

  1. Record the exact expression, scheduler dialect, timezone, and preview start before editing anything.
  2. For 0 9 15 * MON at UTC 2026-07-13 08:59, expect Monday July 13 and Wednesday July 15 under the parser's OR rule.
  3. Remember that the chosen starting minute is excluded and the search stops after 366 days; a missing preview may be a window boundary, not proof that the platform will never run.

Check the runtime environment

Confirm the job is deployed to the right environment, the scheduler timezone is expected, the job is enabled, the run user has permission, and dependencies or network access are available.

Close the loop with logs

Record last run time, next run time, exit code, stdout, stderr, request status code, and retry records. Related tools can help inspect timestamps and status codes.

Frequently asked questions

Will a valid cron expression always run?
No. The job may be disabled, lack permissions, miss environment variables, use a wrong command path, or fail because a dependency is unavailable.
Why does local preview look right but production time is wrong?
Common causes include scheduler timezone, daylight saving time, container environment, or platform dialect differences.
Should I inspect the expression or logs first?
Inspect both. The expression describes the plan; logs prove whether the job actually ran and what happened.
Back to blog