Kubernetes CronJob schedule: syntax, time zone and policies

A CronJob starts Jobs on a repeating schedule. The schedule is cron; the rest is Kubernetes.

From the Kubernetes documentation

Read on 13 November 2026 on kubernetes.io ("CronJob").

• .spec.schedule is required and uses the five cron fields: minute (0-59), hour (0-23), day of the month (1-31), month (1-12) and day of the week (0-6, Sunday to Saturday, or sun to sat).
• It accepts the "Vixie cron" step values (0-23/2, */2).
• A question mark ? has the same meaning as *.
• Shortcuts are allowed: @yearly (or @annually), @monthly, @weekly, @daily (or @midnight), @hourly.
• Example from the page: 0 3 * * 1 means every Monday at 3 AM.

A small CronJob

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-cleanup
spec:
  schedule: "15 3 * * *"
  timeZone: "Asia/Kolkata"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: cleanup
              image: busybox:1.36
              command: ["sh", "-c", "echo cleanup"]

The fields schedule, timeZone and concurrencyPolicy are named in the documentation; the rest is the usual Job template. Check the apiVersion against your cluster's version.

Time zone

Without timeZone, the schedule is read in the time zone of the kube-controller-manager. Setting .spec.timeZone to an IANA name such as Etc/UTC is stable since Kubernetes v1.27. Putting CRON_TZ=... or TZ=... inside the schedule is not supported and fails validation.

Concurrency policy

concurrencyPolicy has three values: Allow (the default; runs may overlap), Forbid (if the previous run has not finished, the new run is skipped) and Replace (the running Job is replaced by the new one). It applies only to Jobs created by the same CronJob.

Missed runs

startingDeadlineSeconds is optional. It gives a deadline in whole seconds for starting a Job that missed its time; after the deadline that run is skipped and counted as failed. If it is not set, there is no deadline. The page cautions that a value under 10 seconds may stop the CronJob from being scheduled, because the controller checks every 10 seconds, and that if more than 100 schedules were missed, the controller records a warning event and starts a Job for the most recent missed one.

History and suspending

successfulJobsHistoryLimit defaults to 3 and failedJobsHistoryLimit to 1. Setting .spec.suspend to true stops new Jobs without affecting running ones; suspended executions count as missed.

Be ready for twice or never

The page says the schedule is approximate: in some circumstances two Jobs might be created, or none. Write the Job so that running it twice does no harm.

This is an independent guide and tool. It is not connected with crontab.guru, Quartz, GitHub, Kubernetes, Spring or the Linux projects named here. Product names belong to their owners.