CronLens

Kubernetes CronJob schedule builder

A CronJob uses five-field cron syntax with a separate timeZone field. Enter a schedule, choose the time zone, and see its plain-English meaning, the next runs and a manifest you can copy. Nothing is uploaded.

    CronJob manifest

    History and favourites (stored only in this browser)

      Nothing saved yet. Expressions you check are saved here, in your browser's local storage, never on a server.

      Runs locally. The expression is never uploaded. The share link keeps it after the # sign, which browsers never send to a server.

      How to use

      1. Enter the five-field schedule (minute, hour, day of month, month, day of week) in the box, or one of the macros the Kubernetes documentation lists: @yearly, @annually, @monthly, @weekly, @daily, @midnight or @hourly.
      2. Type the IANA time zone you want in the Time zone box, for example Asia/Jakarta or Europe/London. The manifest below gets a timeZone line with that value.
      3. Check the list of upcoming runs against what you expect. Look at the offset column around daylight saving changes.
      4. Choose a concurrencyPolicy: Allow (the default) lets runs overlap, Forbid skips a new run while the previous one is still going, and Replace cancels the running Job and starts the new one.
      5. Copy the manifest, replace the placeholder container with your own image and command, and apply it with kubectl as described in the Kubernetes tutorial.

      The name box is trimmed to a valid lowercase name of at most 52 characters, because the documentation limits CronJob names to that length.

      Worked examples

      Mondays at 03:00 in Jakarta

      0 3 * * 1 is the example from the Kubernetes documentation ("weekly on a Monday at 3 AM"). With timeZone: "Asia/Jakarta", which has no daylight saving, the offset is always +07:00.

      Kubernetes CronJob, time zone Asia/Jakarta, runs after 2026-10-01 00:00 UTC
      0 3 * * 1

      1. Mon 2026-10-05 03:00:00 +07:00
      2. Mon 2026-10-12 03:00:00 +07:00
      3. Mon 2026-10-19 03:00:00 +07:00

      A time that does not exist: 01:30 in London on 29 March 2026

      Clocks in London jump from 01:00 to 02:00 that night, so 01:30 never happens on the 29th. Kubernetes does not document what a CronJob does; this tool shows the behaviour observed from the library the controller uses, which skips that day.

      Kubernetes CronJob, time zone Europe/London, runs after 2026-03-27 00:00 UTC
      30 1 * * *

      1. Fri 2026-03-27 01:30:00 +00:00
      2. Sat 2026-03-28 01:30:00 +00:00
      3. Mon 2026-03-30 01:30:00 +01:00

      A time that happens twice: 01:30 in New York on 1 November 2026

      At 02:00 EDT the clocks go back to 01:00 EST, so 01:30 occurs at -04:00 and again at -05:00. The observed behaviour is two runs, one hour apart in real time.

      Kubernetes CronJob, time zone America/New_York, runs after 2026-10-31 00:00 UTC
      30 1 * * *

      1. Sat 2026-10-31 01:30:00 -04:00
      2. Sun 2026-11-01 01:30:00 -04:00
      3. Sun 2026-11-01 01:30:00 -05:00
      4. Mon 2026-11-02 01:30:00 -05:00

      Because those last two behaviours are observed rather than documented, schedule important jobs outside the hour that your zone skips or repeats.

      A stepped star in a day field

      0 0 */2 * 1 in Kubernetes treats */2 as a restriction, so the schedule fires on odd days of the month or on Mondays (this is the same expression that classic cron treats differently; see the builder page):

      Kubernetes CronJob, time zone UTC, runs after 2026-10-01 00:00 UTC
      0 0 */2 * 1

      1. Sat 2026-10-03 00:00:00 +00:00
      2. Mon 2026-10-05 00:00:00 +00:00
      3. Wed 2026-10-07 00:00:00 +00:00
      4. Fri 2026-10-09 00:00:00 +00:00
      5. Sun 2026-10-11 00:00:00 +00:00
      6. Mon 2026-10-12 00:00:00 +00:00

      Limits & gotchas

      • Daylight saving behaviour is observed, not documented. The Kubernetes page says nothing about it. The controller builds its schedule as TZ=<timeZone> <schedule> for the robfig/cron v3 library (visible in the controller source), and the robfig documentation warns that jobs scheduled during a clock change that jumps forward will not run. This tool copies the library's behaviour for the skipped and the repeated hour, and our engine was compared with robfig/cron v3.0.1 on randomly generated schedules across several zones with no differences found. Newer Kubernetes releases may update the dependency.
      • Jobs can be missed or duplicated. The documentation tells you to make jobs idempotent.
      • The 100-missed-schedules rule. After a long outage the controller refuses to catch up if more than 100 runs were missed. A frequent schedule is more exposed than a daily one.
      • startingDeadlineSeconds under 10 may leave the job unscheduled, since the controller checks about every 10 seconds.
      • History and suspension. By default 3 successful and 1 failed Job are kept (successfulJobsHistoryLimit, failedJobsHistoryLimit) and suspend: true pauses new runs.
      • The manifest is a starting point. It uses a placeholder container, so it needs your image and command before it does anything useful. It only contains fields that appear in the Kubernetes documentation.

      FAQ

      Can I put CRON_TZ or TZ inside a Kubernetes CronJob schedule?

      No. The Kubernetes documentation says that specifying a time zone with CRON_TZ or TZ inside .spec.schedule is not officially supported and that validation rejects it. Use the separate .spec.timeZone field instead. The tool here reports such an expression as an error for the same reason.

      What happens if I do not set .spec.timeZone?

      The schedule is interpreted in the local time zone of the kube-controller-manager process, according to the Kubernetes documentation. On a managed cluster you usually cannot see that zone, so set timeZone explicitly and the schedule means the same thing everywhere.

      Is a question mark allowed in a Kubernetes schedule?

      Yes. The documentation states that a ? in the schedule means the same as an asterisk. That differs from Quartz and AWS, where ? has a different job, so an expression copied from those systems is not automatically valid or equivalent here.

      Why did my CronJob not start and report "too many missed start times"?

      The documentation says that if the controller finds more than 100 missed schedules since the last run (or since creation) it does not start the job and logs that error. Setting startingDeadlineSeconds limits how far back the controller counts missed runs. Very small values under 10 seconds may stop the job from being scheduled at all, because the controller only checks every 10 seconds.

      Can a CronJob run twice or not at all?

      The Kubernetes documentation says a CronJob creates a Job roughly once per scheduled time, but that in some circumstances two Jobs might be created or none, and that you should make jobs idempotent. Plan for that: the run times on this page are the scheduled instants, not a guarantee.

      Sources

      Every document above was opened and read on 2026-10-01. Documentation changes; if a page here disagrees with the current docs, trust the docs and tell us.