Do not use one CronJob’s concurrency policy as a global lock

Different scheduled jobs can still overlap even when each forbids its own concurrent runs.

Source facts

Kubernetes CronJob concurrencyPolicy applies only to Jobs created by that same CronJob. Forbid skips a new run when the preceding run is unfinished; Replace substitutes a new run. Jobs from separate CronJobs may run concurrently. Scheduling is approximate, and Kubernetes recommends idempotent Jobs because circumstances can produce duplicate or missed creation.

Source: Kubernetes documentation — CronJob.

Applicability

Review concurrency within one CronJob and coordination between separate schedules.

DSE recommendation

DSE recommends identifying all writers to the same data before selecting a concurrency mode. Use application-level coordination when independent schedules must serialize work. Decide whether a missed schedule or interrupted prior run is acceptable, then record that choice with the task owner. Monitor completion time relative to the schedule so an unexpectedly long run does not silently skip future work. Keep recovery procedures clear about whether a manual rerun can overlap an automatically created Job and how duplicate execution is made safe.

Verification

In a test namespace, observe a long-running task under the chosen policy and inspect which scheduled run is created, skipped, or replaced. Separately exercise two CronJobs against a safe shared target to validate the intended application-level coordination. Record the scheduled time, actual Job identity and shared-target operation identifier. Ask the task owner to decide how to recover a skipped or interrupted run without accidentally conflicting with a later scheduled execution.

Official reference

Kubernetes documentation — CronJob. Reviewed October 20, 2026.