Home › Kubernetes CronJob Generator

Kubernetes CronJob Generator

Generate and validate cron expressions for Kubernetes CronJob resources. Kubernetes uses standard 5-field Linux cron syntax in the schedule field. The guide below covers timezone configuration, concurrencyPolicy, startingDeadlineSeconds and common invalid schedule errors.

Validator Syntax Examples

Kubernetes CronJob Schedule Generator

Standard 5-field cron syntax. Build your schedule below and copy it directly into your Kubernetes manifest.

Quick presets

Minute

Hour

Day

Month

Weekday

* * * * *

Runs every minute

Kubernetes manifest snippet

apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-cronjob
spec:
  schedule: "* * * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: my-job
            image: my-image:latest
          restartPolicy: OnFailure

Kubernetes CronJob Timezone

By default, Kubernetes CronJobs run in the timezone of the kube-controller-manager - usually UTC. Since Kubernetes 1.27, you can set a timezone per CronJob using the timeZone field (IANA format). See the official Kubernetes CronJob docs.

spec:
  schedule: "0 9 * * 1-5"
  timeZone: "Europe/Madrid"

Common timezone values:

timeZone: "UTC"
timeZone: "America/New_York"
timeZone: "America/Los_Angeles"
timeZone: "Europe/London"
timeZone: "Asia/Tokyo"

On clusters older than 1.27, convert your schedule to UTC manually - there is no per-CronJob timezone option. Check your cluster version: kubectl version --short.

ConcurrencyPolicy

Policy	Behaviour
`Allow`	New job starts even if previous is still running (default)
`Forbid`	Skips new job if previous is still running
`Replace`	Cancels current job and starts a new one

Use Forbid for jobs that must not run concurrently (database maintenance, file processing). Use Allow for independent jobs where overlap is acceptable.

startingDeadlineSeconds

If the controller misses a scheduled run (cluster down, controller restart), it will try to catch up. startingDeadlineSeconds limits how late a missed job can start. If the window passes, the job is skipped and counted as missed.

spec:
  schedule: "0 2 * * *"
  startingDeadlineSeconds: 3600  # skip if more than 1 hour late

If more than 100 jobs are missed within the deadline window, the CronJob controller stops scheduling new ones and logs an error. This is a common surprise on clusters that were offline for a long time.

Kubernetes CronJob Invalid Schedule

Kubernetes validates the schedule field at apply time. Common errors:

0 0 31 2 * - February 31st never exists. Kubernetes rejects this as InvalidSchedule.

*/5 * * * * * - 6 fields. Kubernetes uses 5-field syntax, not Quartz. The extra seconds field causes a parse error.

0 25 * * * - Hour 25 is out of range (0-23). The CronJob is created but never fires.

Use the cron expression validator to check your schedule before applying the manifest.

Kubernetes Cron Schedule Examples

Every 5 minutes

*/5 * * * *

Every hour

0 * * * *

Daily database backup at 2 AM UTC

0 2 * * *

Weekdays at 9 AM

0 9 * * 1-5

First of month at midnight

0 0 1 * *

Every Sunday at 3 AM

0 3 * * 0