How is the cron schedule field interpreted?

It's a standard 5-field cron expression (minute, hour, day-of-month, month, day-of-week), evaluated in the timezone configured on the CronJob (or the kube-controller-manager's default if unset). '0 * * * *' runs once an hour on the hour; '*/15 * * * *' runs every 15 minutes; '0 2 * * *' runs once a day at 2am.

What do the three concurrencyPolicy values actually change?

'Allow' (the default) lets multiple runs overlap if a previous Job hasn't finished by the next scheduled time. 'Forbid' skips the new run entirely if the previous one is still active. 'Replace' cancels the still-running Job and starts the new one in its place. Use Forbid or Replace for anything that shouldn't run concurrently with itself, like a task that writes to the same output location.

What does startingDeadlineSeconds do?

It's a grace period, if the CronJob controller misses a scheduled run (e.g. the controller was down), it will still start that run as long as it's within `startingDeadlineSeconds` of the scheduled time; otherwise the missed run is counted as failed and skipped rather than run late.

Why is successfulJobsHistoryLimit worth setting explicitly?

Each run creates a completed Job object (and its Pods) that Kubernetes keeps around for inspection; the default keeps the last 3 successful and 1 failed Job. For a CronJob that runs very frequently, explicitly setting this keeps the namespace from accumulating an unbounded number of old Job objects.

CronJob YAML Generator

Overview

Introduction

A CronJob is a Job that runs on a repeating schedule, database backups, report emails, cleanup sweeps, but getting the cron expression, concurrency policy, and history limits right by hand means juggling several independent, easy-to-forget fields.

This tool builds a CronJob manifest from a form with a validated cron schedule field (plus a few common presets), concurrency policy, and the history/deadline settings that keep a frequently-run CronJob well-behaved.

What Is Kubernetes CronJob Generator?

A form-based generator for the `batch/v1/CronJob` resource, which wraps a Job template under a cron schedule so Kubernetes creates a new Job run at each scheduled time.

It covers the schedule itself, the container's image and command, concurrencyPolicy for controlling overlapping runs, successfulJobsHistoryLimit for cleanup, and an optional startingDeadlineSeconds grace period for missed runs.

How Kubernetes CronJob Generator Works

Your 5-field cron expression is validated against the standard minute/hour/day-of-month/month/day-of-week format before being placed in `spec.schedule`; a few common presets (hourly, daily at midnight, every 15 minutes) are offered as quick-fill buttons.

Image and command build a nested `jobTemplate.spec.template` the same way the standalone Job Generator does, since a CronJob's job template is structurally identical to a Job's spec.

When To Use Kubernetes CronJob Generator

Use it for anything that needs to run repeatedly on a fixed schedule inside the cluster: nightly backups, periodic report generation, scheduled cache warm-ups, or recurring cleanup tasks.

If the task only needs to run once (not on a recurring schedule), use the plain Job Generator instead.

Often used alongside Kubernetes Job Generator.

Features

Advantages

Validates the cron expression's shape before generating output, catching a schedule with the wrong number of fields early.
Includes quick-fill presets for the most common schedules, avoiding a trip to a cron syntax reference for routine cases.
Surfaces concurrencyPolicy and successfulJobsHistoryLimit as explicit fields rather than leaving them at easy-to-forget defaults.

Limitations

Cron validation checks field shape (five whitespace-separated fields using digits, commas, hyphens, slashes, and asterisks) but doesn't verify that ranges are semantically valid (e.g. an hour field of '25').
Doesn't expose `failedJobsHistoryLimit` or `timeZone` separately; both are worth adding by hand if you need non-default failure retention or an explicit timezone.

Examples

A nightly backup CronJob that forbids overlapping runs

Input

name: nightly-backup, schedule: '0 2 * * *', image: myapp/backup:1.4, command: 'backup run', concurrencyPolicy: Forbid, successfulJobsHistoryLimit: 5

Output

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-backup
spec:
  schedule: "0 2 * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 5
  jobTemplate:
    spec:
      template:
        metadata:
          labels:
            app: nightly-backup
        spec:
          restartPolicy: OnFailure
          containers:
            - name: nightly-backup
              image: myapp/backup:1.4
              command: [backup, run]

Runs once a day at 2am; if a previous backup run is still in progress, Forbid skips the new trigger instead of piling up overlapping backups.

Best Practices & Notes

Best Practices

Set concurrencyPolicy to Forbid or Replace for any task that isn't safe to run concurrently with itself, most backup, migration, and report jobs fall in this category.
Set successfulJobsHistoryLimit deliberately for any CronJob running more than a few times a day, so the namespace doesn't accumulate hundreds of completed Job objects.
Set startingDeadlineSeconds for time-sensitive schedules (like a specific-hour report) so a missed run isn't silently executed hours late.

Developer Notes

The cron schedule regex checks that the input has exactly five whitespace-separated fields, each composed only of digits, commas, hyphens, slashes, and asterisks, which rejects obviously malformed input (wrong field count, stray characters) without attempting full semantic range validation. The generated Job template always sets `restartPolicy: OnFailure`, the conventional choice for CronJob-managed Jobs, matching the pattern used across the official Kubernetes CronJob examples.

Kubernetes CronJob Generator Use Cases

Scheduling nightly database backups or snapshot exports
Running a recurring report-generation or notification job at a fixed time each day
Periodically cleaning up expired data, stale cache entries, or temporary files

Common Mistakes

Leaving concurrencyPolicy at the default Allow for a task that isn't safe to run twice at once, causing overlapping runs to corrupt shared state.
Writing a cron expression with the wrong number of fields (four instead of five, or including seconds), which Kubernetes' cron parser rejects at apply time.
Not setting startingDeadlineSeconds and being surprised when a controller outage causes a backlog of missed runs to fire all at once once it recovers.

Tips

Use the Job Generator first to get the command/image/backoff behavior right for a single run, then move those same values into this CronJob generator once you're ready to schedule it.

Kubernetes CronJob Generator