Kubernetes CronJob Overlapping Runs - Fix concurrencyPolicy in CI

A CronJob’s concurrencyPolicy decides what happens when a new scheduled run is due while a previous one is still active. The default Allow lets runs overlap; Forbid skips the new run; Replace cancels the old one.

What this error means

Either many Jobs from the same CronJob run at once and contend for the same resource (with Allow), or scheduled runs silently do not start because a long previous run is still active (with Forbid). The behavior is consistent with whichever policy is set.

kubectl output

# Allow (default): runs stack up
$ kubectl get jobs -l job-name
backup-28....   Running
backup-28....   Running   # previous run never finished, now two overlap

# Forbid: new run skipped
Cannot determine if job needs to be started: Too many missed start times

Common causes

Default Allow lets slow runs overlap

With concurrencyPolicy: Allow, a run that outlasts its schedule interval overlaps the next invocation, doubling load on a shared database or lock.

Forbid silently skips while a run is active

With Forbid, if a previous Job is still running at the next scheduled time, the new run is skipped rather than queued - which can look like the CronJob "stopped firing".

How to fix it

Pick the policy that matches the workload

Choose explicitly instead of relying on the Allow default.

cronjob.yaml

spec:
  concurrencyPolicy: Forbid   # skip if the previous run is still active
  # or Replace to cancel the running one and start fresh
  # or Allow to permit overlap

Bound run time and inspect history

Set activeDeadlineSeconds on the Job template so a hung run cannot block future runs forever under Forbid.
Raise startingDeadlineSeconds if "Too many missed start times" appears after the controller was paused.
Check successfulJobsHistoryLimit / failedJobsHistoryLimit so old Jobs are reaped.

How to prevent it

Set concurrencyPolicy explicitly per CronJob instead of inheriting Allow.
Bound each run with activeDeadlineSeconds so it cannot block the schedule.
Keep run time well under the schedule interval to avoid overlap entirely.