Kubernetes CronJob Schedule Visualizer

Kubernetes CronJob uses standard 5-field cron syntax running in UTC by default. Paste your schedule: value into our free crontab visualizer to see the next 20 run times on a calendar and verify the timing before deploying.

Kubernetes 1.25+ added a timeZone field that lets you specify a timezone — but most clusters still default to UTC. This guide covers both behaviors.

Kubernetes CronJob Schedule Format

The schedule is set in the CronJob spec:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-cronjob
spec:
  schedule: "0 9 * * 1-5"
  timeZone: "America/New_York"   # k8s 1.25+ only
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: worker
            image: my-image:latest

Key behaviors:

• Default timezone: UTC. Without timeZone, the schedule runs in UTC regardless of where your nodes are located.
• timeZone field (k8s 1.25+): Accepts IANA timezone names like America/New_York or Asia/Tokyo. Requires the CronJobTimeZone feature gate (enabled by default in 1.27+).
• Standard 5-field cron. The same syntax as Linux crontab. Quartz/Spring 6-field does not work here.

How to Visualize Your Kubernetes CronJob Schedule

Copy the value from your schedule: field and paste it into the crontab visualizer. The tool shows the next 20 UTC run times.

If your cluster is using the timeZone field, the visualizer's output will be in UTC — convert the hours mentally for your configured timezone, or use the visualizer alongside a UTC offset reference.

Common Kubernetes CronJob schedules:

Goal	Expression
Daily at midnight UTC	0 0 * * *
Hourly	0 * * * *
Every 15 minutes	*/15 * * * *
Weekdays 9 AM UTC	0 9 * * 1-5
Weekly Sunday 2 AM UTC	0 2 * * 0
First of month	0 0 1 * *

Also build expressions from scratch using the cron generator, then verify them in the visualizer.

Sell Custom Apparel — We Handle Printing & Free Shipping

ConcurrencyPolicy and startingDeadlineSeconds

Two settings affect when and whether CronJob instances actually run:

concurrencyPolicy: Controls what happens when a job is still running when the next schedule triggers:

• Allow (default): Start a new job even if the previous is still running. Can lead to many parallel instances.
• Forbid: Skip the new scheduled run if the previous job hasn't finished.
• Replace: Kill the current job and start a new one.

startingDeadlineSeconds: How long (in seconds) Kubernetes will wait after a missed schedule before giving up. If a CronJob is skipped more than 100 times (e.g., after cluster downtime), Kubernetes won't try to catch up — it simply starts from the next scheduled time.

spec:
  schedule: "*/5 * * * *"
  concurrencyPolicy: Forbid
  startingDeadlineSeconds: 200

Debugging Kubernetes CronJob Timing Problems

Check the CronJob's schedule and last run with:

kubectl get cronjob
# Shows: SCHEDULE, SUSPEND, ACTIVE, LAST SCHEDULE, AGE

kubectl describe cronjob my-cronjob
# Shows events, schedule history, job references

Common issues:

• Job suspended: Check kubectl get cronjob — if SUSPEND is True, manually or programmatically suspended. Run kubectl patch cronjob my-cronjob -p '{"spec":{"suspend":false}}' to resume.
• Missed 100+ schedules: After extended cluster downtime, if the CronJob missed more than 100 scheduled runs, it won't catch up. It will resume on the next scheduled time going forward.
• Node timezone vs UTC: Confirm your cluster scheduler (kube-controller-manager) timezone. Most managed clusters run the controller in UTC, but on-prem clusters may differ.

Validate the schedule expression first with the visualizer to rule out expression errors before debugging cluster-level issues.

Frequently Asked Questions

Does Kubernetes CronJob support seconds in the cron expression?

No. Kubernetes CronJob uses standard 5-field cron syntax (minute hour day month weekday) — seconds are not supported. The minimum scheduling granularity is 1 minute. For sub-minute intervals, use a cron job that runs every minute and loops internally with sleep commands, or use a different mechanism like a long-running deployment.

How do I set a Kubernetes CronJob to a specific timezone?

In Kubernetes 1.25+, add "timeZone: America/New_York" (or your IANA timezone) to the CronJob spec alongside the schedule. This requires the CronJobTimeZone feature gate, which is enabled by default in k8s 1.27+. On older clusters, you must convert your desired time to UTC manually and write the expression in UTC.

Why did my Kubernetes CronJob miss a scheduled run?

Common causes: (1) concurrencyPolicy: Forbid — the previous job is still running; (2) startingDeadlineSeconds expired — the job start was delayed past the deadline; (3) cluster was down or the controller was restarting; (4) the job was suspended (spec.suspend: true). Check "kubectl describe cronjob " for events that explain missed runs.