Cron Jobs in Production: crontab, UTC, DST & Kubernetes CronJobs
People search cron expression, crontab generator, and cron every 5 minutes while operators worry about UTC vs local time, daylight saving gaps, and overlapping runs. This guide explains five-field syntax, CRON_TZ, systemd timers as an alternative, and Kubernetes CronJob semantics—plus idempotency patterns so retries do not double-charge.
Reliability: idempotency, locks, and dead-letter queues
Assume at-least-once delivery. Use distributed locks (Redis SET NX), database uniqueness constraints, or natural dedupe keys. Emit metrics for duration, failure rate, and last-run timestamp—alert when a job silently stops executing because cron syntax was wrong after deploy.
DST and the 2:30 AM problem
Nonexistent local times and repeated hours break naive schedules. Prefer UTC for global systems; if business rules require local time, document how you handle spring/fall transitions.
Observability
Log scheduled fire time vs actual start—queue lag indicates capacity issues.
Idempotency, locking, and exactly-once illusions
Cron guarantees at-least-once execution in distributed systems—design jobs to tolerate duplicates with advisory locks, lease tables, or external coordinators like Redis Redlock (know its limits). For financial settlement windows, prefer message queues with consumer groups over naked shell scripts. When correlating runs, log an idempotency key alongside wall-clock timestamps; pair with Unix timestamps for cross-region debugging.
Managed schedulers: EventBridge, Cloud Scheduler, and Quartz
Cloud-native schedulers add rate limits, retries, and DLQs—map their cron dialects carefully (some support seconds fields). JVM stacks often use Quartz with persistent stores; ensure misfire instructions match business tolerance (fire now vs skip). Test daylight-saving transitions in the target region, not only in developer laptops set to UTC.
Security: least privilege and secret rotation
Cron jobs frequently hold database credentials or API tokens—rotate them on the same cadence as interactive users. Avoid dumping environment variables to logs when commands fail. If scripts curl internal endpoints, enforce network policies so compromised hosts cannot pivot broadly.
Recommended tools on Universal Dev Tools
Translate five-field expressions to human-readable text before code review.
Compare UTC instants against local wall-clock expectations around DST edges.
Review changes to crontab exports or Helm values side by side.
Sanity-check business-day offsets and holiday calendars adjacent to cron schedules.
Related guides on this blog
Frequently Asked Questions
What are the five fields in a cron expression?
Traditional Unix cron uses minute, hour, day-of-month, month, day-of-week. Some systems add seconds or use six-field variants—read your scheduler docs (cron vs Kubernetes CronJob vs AWS EventBridge).
How does timezone affect cron?
Crontabs usually follow the server TZ unless CRON_TZ is set. Use UTC for global systems or explicitly document local offsets. DST transitions can skip or duplicate runs—test spring forward/fall back.
What is the difference between cron and systemd timers?
systemd timers can catch up missed runs and integrate with journald; cron is simpler but less expressive for dependency chains.
How do I parse cron expressions to human-readable text?
Libraries translate cron to natural language for UI. Validate with next-run calculators against your target TZ.
What Kubernetes CronJob pitfalls exist?
ConcurrencyPolicy, startingDeadlineSeconds, and backoff limits matter. Long-running jobs can overlap; use suspend or Jobs with TTL.
Can cron run sub-minute schedules?
Standard cron lacks sub-minute precision; use continuous workers or specialized schedulers for high-frequency tasks.
Wrapping up
Parse expressions to human-readable strings during design reviews, then monitor execution—not just exit codes.
Cron Expression Parser →