10 Cron Mistakes That Break Production

Cron looks simple until it silently shifts a backup by a day or fires twice during a daylight-saving transition. Most incidents come from a small set of repeatable mistakes rather than exotic syntax.

1. Confusing Sunday as 0 vs 7

Unix cron accepts both 0 and 7 for Sunday. Some platforms accept only one numbering scheme. Always verify the scheduler documentation and test the expression in a validator before production.

2. Ignoring timezone defaults

GitHub Actions and Vercel Cron evaluate schedules in UTC unless configured otherwise. A job intended for 09:00 Istanbul time may run at 06:00 UTC in winter. Use explicit IANA timezones where supported.

3. DST spring-forward gaps

A daily job at 02:30 local time may not run on the spring-forward day when that clock time does not exist. Use CronWizard DST checker to preview skipped or repeated hours.

4. Assuming cron means "every N minutes after start"

*/15 does not mean fifteen minutes after deployment. It means minutes 0, 15, 30, and 45 of each hour. Long-running jobs can overlap the next slot.

5. Using Quartz syntax on Unix crontab

Question marks, L, W, and # are not valid in standard crontab. Spring and Quartz use six or seven fields. Validate against the target platform dialect.

6. Constraining both day-of-month and day-of-week incorrectly

Some schedulers require one field to be * or ? when the other is constrained. AWS EventBridge and Vercel enforce stricter rules than classic Vixie cron.

7. No idempotency or locking

Delayed runs, retries, and overlapping executions can duplicate side effects. Use lease locks, deduplication keys, or at-most-once guards for mutating work.

8. High-frequency jobs without cost awareness

Every-minute schedules multiply API calls, database queries, and cloud invocations. Model cost before copying a tutorial expression into production.

9. Skipping next-run preview

Human-readable text can hide subtle field interactions. Preview the next five to ten runs in the target timezone before merging.

10. Deploying without export review

Kubernetes CronJob, systemd timer, and GitHub Actions YAML each embed the schedule differently. Generate an export template and review timezone fields in the manifest.

Catch issues before deploy

Use the CronWizard builder for visual schedules, the validator for paste-and-check workflows, and the DST analyzer when local wall-clock time matters. Share a public /s/ link with teammates for review.