CronJob Schedules and concurrencyPolicy

Application Design and Build / Guide 11 of 44 / Intermediate

• Kubernetes1.36.4
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 15 min
• Reviewed23 August 2026

Written against the versions above. The Job names a CronJob generates end in a number - `tick-29790909` - which is the scheduled time in minutes since the epoch, not a random suffix. Two Jobs from consecutive minutes therefore have consecutive numbers, which makes the gap left by a skipped run visible in the listing.

Before you start

• A cluster and kubectl. This guide waits for real schedule ticks, so it takes a few minutes of wall-clock time.
• The session creates namespace ckad-cron, a CronJob tick running every minute, and a CronJob slow whose job takes 150 seconds on a 60-second schedule.

1. 1

   A Job every minute

   kubectl create cronjob generates this in one line - no jobTemplate nesting typed by hand. After seventy-five seconds there are Jobs in the namespace, and the CronJob records when it last fired:

   SCHEDULE      LAST                   SUCCESSHIST   FAILHIST
   */1 * * * *   2026-08-23T03:...Z   3             1

   successfulJobsHistoryLimit: 3, failedJobsHistoryLimit: 1 - both defaults, and both are why a CronJob that has run for a week has only three Jobs to show for it. If you are looking for the run from an hour ago, it has been garbage collected.

   The logs of every run at once, with the Job name prefixed, is the query worth knowing:

   kubectl logs -l batch.kubernetes.io/job-name --tail=1 --prefix=true

   $kubectl create namespace ckad-cronnamespace/ckad-cron created$kubectl -n ckad-cron create cronjob tick --image=busybox:1.36 --schedule='*/1 * * * *' -- /bin/sh -c 'date +%H:%M:%S'cronjob.batch/tick created$kubectl -n ckad-cron get cronjob tickNAME   SCHEDULE      TIMEZONE   SUSPEND   ACTIVE   LAST SCHEDULE   AGEtick   */1 * * * *   <none>     False     0        <none>          0s$sleep 75; kubectl -n ckad-cron get jobsNAME            STATUS     COMPLETIONS   DURATION   AGEtick-29790908   Complete   1/1           3s         72stick-29790909   Complete   1/1           2s         12s$kubectl -n ckad-cron get cronjob tick -o 'custom-columns=SCHEDULE:.spec.schedule,LAST:.status.lastScheduleTime,SUCCESSHIST:.spec.successfulJobsHistoryLimit,FAILHIST:.spec.failedJobsHistoryLimit'SCHEDULE      LAST                   SUCCESSHIST   FAILHIST*/1 * * * *   2026-08-23T03:09:00Z   3             1

   Expected resultOne Job per minute, and the two history limits at their defaults.

   Success conditionYou have a CronJob and know why old runs disappear.

2. 2

   What happens when a run overruns

   slow sleeps 150 seconds on a */1 * * * * schedule, so by the time the second tick comes due the first is still going. With concurrencyPolicy: Forbid:

   JOB             ACTIVE   SUCCEEDED
   slow-29790910   1        <none>
   tick-29790909   <none>   1
   tick-29790910   <none>   1
   tick-29790911   <none>   1

   One slow Job across two ticks. tick produced ...909, ...910 and ...911; slow produced only ...910. The ...911 run was due and was skipped.

   POLICY   ACTIVE          LAST
   Forbid   slow-29790910   2026-08-23T03:10:00Z

   The skip is silent - describe cronjob recorded no event for it. Nothing tells you a run did not happen except the gap in the numbering, which is worth knowing before you rely on a schedule for something that matters.

   The three policies:

   • Allow (default) - runs overlap. Fine for idempotent work, bad for anything that writes.
   • Forbid - skip the new run, as here.
   • Replace - kill the running Job and start the new one.

   $sleep 140; kubectl -n ckad-cron get jobs -l app!=none -o 'custom-columns=JOB:.metadata.name,ACTIVE:.status.active,SUCCEEDED:.status.succeeded'JOB             ACTIVE   SUCCEEDEDslow-29790910   1        <none>tick-29790909   <none>   1tick-29790910   <none>   1tick-29790911   <none>   1$kubectl -n ckad-cron get cronjob slow -o 'custom-columns=POLICY:.spec.concurrencyPolicy,ACTIVE:.status.active[*].name,LAST:.status.lastScheduleTime'POLICY   ACTIVE          LASTForbid   slow-29790910   2026-08-23T03:10:00Z

   Expected resultOne active slow Job over two schedule ticks.

   Success conditionYou can choose a concurrency policy and know the skip will be silent.

3. 3

   Suspend it

   NAME   SCHEDULE      TIMEZONE   SUSPEND   ACTIVE   LAST SCHEDULE   AGE
   tick   */1 * * * *   <none>     True      0        34s             3m38s

   SUSPEND True and nothing further is created. Already-running Jobs are left alone - suspend stops *scheduling*, it does not stop work in flight.

   This is the correct answer to "stop this CronJob" on the exam and in production, and it is much better than deleting it, because the object and its history stay. Unsuspend with the same patch and false.

   Note TIMEZONE : without spec.timeZone the schedule is interpreted in the controller's time zone, which on most clusters is UTC and is very rarely what a business schedule means.

   $kubectl -n ckad-cron patch cronjob tick --type=merge -p '{"spec":{"suspend":true}}'cronjob.batch/tick patched$kubectl -n ckad-cron get cronjob tick -o 'custom-columns=SCHEDULE:.spec.schedule,LAST:.status.lastScheduleTime,SUCCESSHIST:.spec.successfulJobsHistoryLimit,FAILHIST:.spec.failedJobsHistoryLimit'SCHEDULE      LAST                   SUCCESSHIST   FAILHIST*/1 * * * *   2026-08-23T03:09:00Z   3             1$kubectl -n ckad-cron get cronjob tick -o jsonpath='{.spec.suspend}'true$kubectl delete namespace ckad-cron --wait=falsenamespace "ckad-cron" deleted

   Expected resultSUSPEND True and no further Jobs.

   Success conditionYou can stop a schedule without destroying it.

Troubleshooting

• A CronJob's older runs have disappeared.

  Why: successfulJobsHistoryLimit defaults to 3 and failedJobsHistoryLimit to 1.

  Fix:Raise them, or ship the logs somewhere. Do not rely on the Jobs being there.

• Runs are overlapping and corrupting each other.

  Why: concurrencyPolicy defaults to Allow.

  Fix:Set Forbid to skip, or Replace to cancel the running one.

• A scheduled run silently did not happen.

  Why: Forbid skipped it because the previous run was still active, or the controller was down past startingDeadlineSeconds.

  Fix:Compare the Job name suffixes - they are consecutive scheduled minutes, so a gap is a skip. No event is emitted.

• The job runs at the wrong time of day.

  Why: No spec.timeZone, so the schedule uses the controller's zone - usually UTC.

  Fix:Set spec.timeZone: "Europe/London" or similar.

Official sources

• CronJob
• Running Automated Tasks with a CronJob
• CronJob API