Kubernetes CronJob Generator
Build a CronJob with the fields that actually decide its behaviour: the timezone, the starting deadline that prevents the 100 missed schedules cliff, and a hard timeout for a job that hangs rather than fails. The output is checked by our own validator as you type.
cronjob.yaml
updates as you typeCommon mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Leaving concurrencyPolicy at Allow
Runs overlap when one takes longer than the interval, and they accumulate until the node runs out.
Instead:Forbid for anything not safe to run twice, Replace where the newest run supersedes.
Not setting the history limits
Completed Jobs and their pods accumulate indefinitely, which clutters the namespace and eventually pressures etcd.
Instead:Set successfulJobsHistoryLimit and failedJobsHistoryLimit deliberately.
Assuming a missed schedule is caught up
If the controller is down past startingDeadlineSeconds, the run is skipped entirely and only an event records it.
Instead:Set startingDeadlineSeconds knowingly, and alert on missed schedules.
The four things that break a CronJob
A CronJob is a schedule wrapped around a Job wrapped around a pod, and each layer has its own timeout, its own retry count and its own idea of what failure means. Almost every CronJob problem is one of these four, and none of them produce an error at apply time.
It runs in UTC unless you say otherwise
There is no cluster timezone and no inherited one. Without spec.timeZone the schedule is interpreted in UTC by the controller manager, so a job written for 3am local time runs at 3am UTC. The field exists from 1.27; on anything older it is dropped silently and you are back in UTC without being told.
spec:
schedule: "0 3 * * *"
timeZone: "Europe/London" # 1.27 and later
# without timeZone, "0 3 * * *" is 03:00 UTC, which is
# 04:00 in London for half the year. The job does not
# shift with daylight saving unless timeZone is set.The 100 missed schedules cliff
This is the one almost nobody knows about. If startingDeadlineSeconds is unset, the controller counts every schedule it missed since the last successful run. Once that count passes 100 it stops scheduling the CronJob permanently, logs a single line, and sets no condition and no event that a dashboard would pick up. A per-minute job needs less than two hours of controller downtime to trip it.
# a job every minute, controller down for 2 hours
# -> 120 missed schedules -> over the limit
# -> "Cannot determine if job needs to be started"
# -> never runs again until someone recreates it
spec:
startingDeadlineSeconds: 300
# with a deadline set, the controller only looks back
# 300 seconds, so the count can never reach 100.Overlapping runs are the default
concurrencyPolicy defaults to Allow, so if a run takes longer than the interval the next one starts alongside it. For anything touching a database or a shared file this compounds: the slower it gets, the more copies are running, which makes it slower. Forbid skips the run entirely rather than queueing it, and Replace kills the one in flight.
Allow run 1 ####################
run 2 ####################
run 3 ####################
Forbid run 1 ####################
run 2 (skipped, and it does not run later)
Replace run 1 ######x killed
run 2 ####################Failure and hanging are different, and only one is handled
backoffLimit counts failures. A job that hangs has not failed, so backoffLimit never fires and the job runs until something else stops it. That something has to be activeDeadlineSeconds. With concurrencyPolicy: Forbid, one hung job also blocks every future run indefinitely, which is how a CronJob stops silently.
backoffLimit: 3 retries after a failure
activeDeadlineSeconds: 3600 hard stop, failure or not
# without the deadline:
# job hangs -> never fails -> never retried
# -> Forbid means run 2, 3, 4... are all skipped
# -> the schedule appears to have stopped workingThe name limit is 52, not 63
The controller builds each Job name by appending a timestamp to the CronJob name, and Job names are limited to 63 characters like everything else. A CronJob name over 52 characters therefore applies cleanly and then fails to create every Job it schedules, with the error appearing only in the controller's events.
metadata:
name: a-52-character-name-at-most
# controller creates: <name>-28472910
# ^ up to 11 more characters