How to Schedule a Recurring Task With a Kubernetes CronJob

What a CronJob actually does

A Kubernetes CronJob is the in-cluster equivalent of a crontab entry. At each time its schedule fires, the CronJob controller creates a Job, and that Job runs a pod that executes your task and exits. The three parts you always set are the schedule (when it runs), the jobTemplate (what it runs), and the history limits (how many finished Jobs to keep around).

The schedule field uses standard five-field cron syntax:

┌───────── minute (0-59)
│ ┌─────── hour (0-23)
│ │ ┌───── day of month (1-31)
│ │ │ ┌─── month (1-12)
│ │ │ │ ┌─ day of week (0-6, Sun=0)
│ │ │ │ │
*/5 * * * *   → every 5 minutes
0 * * * *     → top of every hour
0 3 * * *     → 03:00 every day (a nightly backup)

Write the CronJob manifest

Create cronjob.yaml. This one runs a cleanup task every five minutes and keeps only the last three successful Jobs:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: cleanup
spec:
  schedule: "*/5 * * * *"
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
          - name: cleanup
            image: busybox:1.36
            command: ["sh", "-c", "echo pruning old rows; sleep 1"]

A few details that matter:

• apiVersion: batch/v1 is the stable API since Kubernetes 1.21 - do not use the old batch/v1beta1.
• restartPolicy: Never (or OnFailure) is required on a Job pod template. The default Always is invalid for a Job and the manifest will be rejected.
• successfulJobsHistoryLimit bounds how many completed Jobs (and their pods) stick around. Without it, finished pods accumulate in the namespace until they clutter kubectl get pods and consume the namespace quota.

Apply and verify

kubectl apply -f cronjob.yaml
kubectl get cronjob cleanup

kubectl get cronjob shows the schedule, the suspend state, and the last-run columns:

NAME      SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
cleanup   */5 * * * *   False     0        <none>          8s

LAST SCHEDULE stays <none> until the schedule first fires. You do not have to wait five minutes to test the task - trigger a one-off Job from the CronJob's own pod spec:

kubectl create job --from=cronjob/cleanup test-run
kubectl logs job/test-run

That runs the exact same container immediately, so you can confirm it does the right thing and exits cleanly before trusting the schedule.

Stop overlapping runs

If a run can take longer than the interval between runs, add a concurrencyPolicy so a slow Job does not overlap the next scheduled one:

spec:
  schedule: "*/5 * * * *"
  concurrencyPolicy: Forbid

Forbid skips the new run if the previous one is still going; Replace kills the running Job and starts fresh. The default, Allow, lets them overlap - which is usually not what you want for a cleanup or backup task. Getting the schedule right and choosing the concurrency policy are the two things people most often get wrong.