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.

Suspending a CronJob without losing the next run

You can pause a CronJob in place with spec.suspend: true:

kubectl patch cronjob nightly-cleanup -p '{"spec":{"suspend":true}}'

While suspended, the controller stops creating new Job objects. The catch — every scheduled time during the pause is recorded as a missed run. If more than 100 misses pile up before you unsuspend, the controller refuses to start any further runs and logs:

Cannot determine if job needs to be started.
Too many missed start time (> 100).
Set or decrease .spec.startingDeadlineSeconds or check clock skew.

A schedule of */5 * * * * hits the 100-miss limit in about 8 hours, so an overnight suspension is enough to brick the CronJob.

The fix is to set startingDeadlineSeconds to a small window — anywhere from 60 to 300 seconds is typical. The controller then only counts misses inside that window instead of from the last successful run. The next scheduled time after you unsuspend runs normally; everything before the window is silently ignored, which is what you want for most batch jobs.

spec:
  suspend: false
  startingDeadlineSeconds: 180
  schedule: "*/5 * * * *"

If you genuinely need every missed run to fire (e.g. billing rollups), don’t use suspend at all — disable the workload at the application layer and keep the CronJob ticking, or recompute the missed runs from a checkpoint when the system comes back.

When should I use KEDA’s cron trigger instead of a CronJob?

A CronJob runs a Job on a schedule — a fresh pod that does its work and exits. KEDA’s cron scaler does something fundamentally different: it scales an existing Deployment up at a start time and back down at an end time, so a long-running service handles the load while it’s “on” and scales to zero when it’s “off”.

A KEDA ScaledObject with a cron trigger looks like this:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: business-hours
spec:
  scaleTargetRef:
    name: my-api
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
    - type: cron
      metadata:
        timezone: America/Los_Angeles
        start: 0 8 * * 1-5
        end: 0 18 * * 1-5
        desiredReplicas: "5"

The two patterns can coexist in the same cluster. Use a CronJob for batch work, KEDA cron for traffic shaping.

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.