Kubernetes

Last verified: 2026-05-15

Five fields, plus a YAML wrapper

Kubernetes CronJob uses standard 5-field Unix cron, embedded in a YAML schedule string. The cron implementation comes from the controller-manager (which uses the robfig/cron Go library), so behavior matches Linux cron almost exactly. The interesting parts are the surrounding fields.

.spec.timeZone (stable since 1.27)

By default, Kubernetes CronJob schedules are interpreted in the controller-manager's local time, which is typically UTC. Since v1.27 you can set .spec.timeZone: "Europe/Berlin" on the CronJob — the controller uses the IANA database baked into the controller-manager binary, so make sure your cluster is recent enough to have the zone you want.

Concurrency policy

• Allow — default; new runs start regardless of whether a previous run is still executing.
• Forbid — if a previous run hasn't finished, the new run is skipped.
• Replace — if a previous run hasn't finished, it is cancelled and the new run starts.

Missed runs

If the controller-manager is down when a scheduled run should fire, the run is skipped — by default. To allow the controller to catch up on missed runs, set .spec.startingDeadlineSeconds. Tune this carefully: 200 seconds for a quarterly job is too tight; 3600 seconds for a per-minute job will queue up an avalanche on recovery.

History limits

.spec.successfulJobsHistoryLimit (default 3) and .spec.failedJobsHistoryLimit (default 1) control how many completed Job objects are retained. Crank these down to 0 in clusters with many CronJobs to reduce etcd pressure.

Found something inaccurate? Email hello@cronpreview.com.