Description
startingDeadlineSeconds sets how late a job may start after missing its scheduled time. Without it, an old job may start after a controller delay or cluster problem. This does not mean every missed run is always replayed.
The setting does not limit the duration of a running Job. It can be omitted when late execution is acceptable; time-sensitive jobs need a clear allowed delay.
Potential impact
- A delayed job may act on data or state at an inappropriate time.
- An overly short deadline can skip runs during normal controller delays.
Remediation
- If late starts must be bounded, set spec.startingDeadlineSeconds to an acceptable delay. Account for the controller’s checking interval and operational delays.
- Make jobs safe to run more than once and review concurrencyPolicy and retries. Set the Job’s activeDeadlineSeconds separately if execution duration must be limited.
Examples
These examples compare scheduling settings. Specify the actual command and a verified image version separately, and adjust 100 seconds to the job’s requirements.
Before
apiVersion: batch/v1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
restartPolicy: OnFailure
There is no explicit deadline for delayed starts. Review whether late execution is acceptable.
After
apiVersion: batch/v1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
startingDeadlineSeconds: 100
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
restartPolicy: OnFailure
A start deadline of 100 seconds after the scheduled time is set. It does not terminate a Job 100 seconds after it starts.