TechCompare LogoTechCompare

Kubernetes CronJob syntax: how K8s cron scheduling differs from Linux cron

Kubernetes CronJobs are the standard way to run scheduled workloads in K8s. The cron syntax is identical to Linux. The concurrency, history, and deadline policies are where you need to think differently from a traditional crontab. Set concurrencyPolicy explicitly, then keep the 3 successful and 1 failed history defaults or override them to match your retention needs.

Kubernetes CronJobs use the standard 5-field cron syntax with optional spec fields around it. To run at local midnight, use schedule: '0 0 * * *' with timeZone: 'America/New_York'. The field is .spec.timeZone. Putting CRON_TZ or TZ inside .spec.schedule isn't supported and fails validation.

By TechCompare · Updated

Schedule pattern
Kubernetes CronJob
kubernetes
Category
Platforms
Cloud and container scheduling

How this is calculated

Kubernetes adds three features on top of standard cron: concurrencyPolicy (Forbid, Replace, or Allow) controls what happens when a previous Job is still running, successfulJobsHistoryLimit and failedJobsHistoryLimit control how many finished Jobs are retained, and startingDeadlineSeconds sets a tolerance for missed schedules. The history limits default to 3 successful Jobs and 1 failed Job. Each CronJob invocation creates a Job, which then starts one or more Pods. An every-5-minutes schedule creates 288 Jobs per day, but the controller cleans finished history down to the configured limits.

Verdict

The cron string is portable, but Kubernetes changes the operational model in ways that matter. Each invocation creates a Job and its Pods, so an every-5-minutes schedule starts 288 Jobs daily. Forbid on concurrencyPolicy prevents overlap. The default successfulJobsHistoryLimit of 3 and failedJobsHistoryLimit of 1 keep finished Jobs from growing without limit, and you can set either value to 0 for no retained history. startingDeadlineSeconds controls how late a missed run may start.

More Cron scenarios

Frequently asked questions

Is Kubernetes CronJob syntax the same as Linux cron?
The 5-field schedule format is identical, so everything you know about 0 0 * * * carries over directly. K8s adds the optional .spec.timeZone field, which Linux cron lacks at the job level. The operational model is what actually differs: every invocation creates a fresh Job and its Pods instead of a process on a long-lived host.
What does concurrencyPolicy do on a Kubernetes CronJob?
It controls overlap when a previous run is still going. Forbid skips the new run entirely (the safe default for jobs that must not run twice), Replace kills the old Pod and starts fresh, and Allow lets both run. An every-5-minutes job with Allow and no internal locking will stack up Pods the moment any run exceeds 5 minutes.
How do I stop completed CronJob pods from piling up?
Kubernetes defaults successfulJobsHistoryLimit to 3 and failedJobsHistoryLimit to 1, so the CronJob controller automatically removes older finished Jobs instead of retaining every run forever. Set the fields explicitly when you want different retention, including 0 to retain none. An every-5-minutes CronJob still creates 288 Jobs per day, but it doesn't keep all 288 under the defaults.