Kubernetes CronJob Schedule Generator

• spec.schedule takes standard 5-field cron — no seconds field, no L/W/# tokens
• spec.timeZone (stable in K8s 1.27) pins the schedule to an IANA timezone — set it explicitly
• concurrencyPolicy decides what happens when a run overlaps the previous one: Allow (default), Forbid, or Replace
• startingDeadlineSeconds under 10s can silently kill schedules after missed starts — set it generously or not at all
• 100 consecutive missed schedules without a deadline → the CronJob stops scheduling entirely

Frequently Asked Questions

What cron syntax does a Kubernetes CronJob accept?

Standard 5-field cron (minute hour day-of-month month day-of-week) with ranges, lists, and steps, plus the @hourly/@daily/@weekly/@monthly macros. No seconds field, and no Quartz-style L, W, or # tokens. The generator above validates against this grammar.

What timezone does spec.schedule run in?

Whatever spec.timeZone says (IANA name, stable since Kubernetes 1.27). If unset, the kube-controller-manager's local timezone applies — UTC on almost all managed clusters. Always set it explicitly; with a real timezone set, DST transitions are handled automatically.

Why did my CronJob stop scheduling entirely?

The classic cause: no startingDeadlineSeconds set, and 100+ consecutive schedules were missed (controller down, cluster paused, suspend: true forgotten) — the controller then refuses to schedule it again. Recreate the CronJob or set a startingDeadlineSeconds. Also check spec.suspend and that recent Jobs aren't failing before the pod starts.

How do I stop runs from overlapping?

Set concurrencyPolicy: Forbid — a tick is skipped while the previous Job still runs. Note it's best-effort per CronJob, not a distributed lock: if your job must never run twice concurrently across retries and manual triggers, add a lock inside the job (database advisory lock, lease object).

Can a CronJob run every 30 seconds?

Not natively — cron's smallest unit is one minute. Common workarounds: a Deployment with an in-process scheduler for sub-minute work, or one CronJob per minute-offset pattern with an in-container sleep. If you're reaching for 30-second cron, a long-running worker with a ticker is usually the better design.