Kubernetes CronJob Schedule Generator

A Kubernetes CronJob schedule is a standard 5-field Unix cron string set in spec.schedule — 0 9 * * 1-5 runs every weekday at 9 AM. The form above generates the schedule string and a complete CronJob YAML manifest with timezone, concurrency policy and starting-deadline fields filled in correctly.

What is the cron syntax used by Kubernetes CronJob?

minute  hour  day-of-month  month  day-of-week
  0      9         *          *        1-5
 0–59  0–23      1–31       1–12     0–6 (Sun=0)

Above: 0 9 * * 1-5 — every weekday at 9 AM. Same exact syntax you’d put in a Linux crontab.

Kubernetes also accepts shortcuts: @yearly, @monthly, @weekly, @daily, @hourly. Most tooling expands them in pre-flight, so the equivalents in the table below produce identical behavior. Use whichever is more readable for you.

Common Kubernetes CronJob schedules

What does a complete CronJob YAML manifest look like?

Once you’ve picked a schedule, here’s a full CronJob spec you can paste in:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-cleanup
  namespace: default
spec:
  schedule: "0 2 * * *"
  timeZone: "America/Los_Angeles"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  startingDeadlineSeconds: 300
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 1800
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: cleanup
              image: my-org/cleanup:1.4.0
              command: ["/usr/local/bin/cleanup", "--days=7"]
              resources:
                requests:
                  cpu: 100m
                  memory: 128Mi
                limits:
                  memory: 256Mi

The bits that matter:

• schedule — the cron string you generated above.
• timeZone — IANA timezone (added in Kubernetes 1.25, stable in 1.27). Without it, the schedule runs in the controller’s timezone, usually UTC.
• concurrencyPolicy: Forbid — refuses to start a new run while the previous is still going. Defaults to Allow.
• startingDeadlineSeconds: 300 — if the controller can’t start the run within 5 minutes of its scheduled time, skip it. Without this, missed runs catch up indefinitely after a controller outage, which can cause a thundering herd.
• successfulJobsHistoryLimit / failedJobsHistoryLimit — how many completed Job objects to keep around. Defaults are 3 and 1 — explicit is good practice.
• backoffLimit — how many times the underlying Job retries on failure before giving up.
• activeDeadlineSeconds — kills any single run that goes past 30 minutes here. Pair with restartPolicy: OnFailure.

Three CronJob mistakes that bite in production

1. Default concurrency. concurrencyPolicy defaults to Allow. If your job sometimes runs longer than its schedule interval (a 5-minute schedule with an 8-minute run), you’ll quietly stack up parallel jobs that fight over the same resources. Always set this explicitly.

2. No timezone before 1.25. Pre-1.25 clusters run schedules in the controller’s local time, which is whatever the cloud provider set — usually UTC, but not guaranteed. If you wrote 0 9 * * * thinking “9 AM Pacific” and your controller is on UTC, you got 9 AM UTC = 1 or 2 AM PT. Upgrade to 1.27+ and use timeZone.

3. startingDeadlineSeconds interaction with controller restarts. If you set this too short (under 10s) and the controller restarts during a deployment, you’ll see MissedSchedule events and silently dropped runs. 60–300 seconds is the safer range for most jobs. Don’t set it at all if missed runs must eventually fire.

Related

• Generic cron expression builder — for any cron flavor, with platform mode toggle.
• AWS EventBridge cron generator — 6-field AWS syntax with ? rule and CloudFormation/Terraform examples.