Description
CronJob starting_deadline_seconds limits how late a job may start after missing its scheduled time. If omitted, this start-delay limit does not apply and a delayed job may run later. Not every missed run is guaranteed to be replayed.
This is not a maximum runtime for an active Job. Jobs that tolerate late execution may omit it; time-sensitive jobs should have a deliberate allowed delay.
Potential impact
- A long-delayed job can inappropriately affect current data or state.
- An overly short deadline can skip runs even during ordinary controller delays.
Remediation
- Where late execution must be limited, set
starting_deadline_secondsto the acceptable delay. Account for the controller’s check interval and operational delays. - Make jobs safe to run more than once and review concurrency_policy and failure retries. Configure the Job’s active_deadline_seconds separately if execution time must be limited.
Examples
These existing examples use kubernetes_cron_job syntax. Use kubernetes_cron_job_v1 for configurations using the current API. The after value of 10 seconds is a short illustration, not a suitable default for every job.
Before
hcl
resource "kubernetes_cron_job" "example" {
metadata {
name = "demo"
}
spec {
schedule = "1 0 * * *"
job_template {
metadata {}
spec {
template {
metadata {}
spec {
container {
name = "hello"
image = "busybox"
command = ["/bin/sh", "-c", "date; echo Hello from the Kubernetes cluster"]
}
}
}
}
}
}
}
After
hcl
resource "kubernetes_cron_job" "example" {
metadata {
name = "demo"
}
spec {
schedule = "1 0 * * *"
starting_deadline_seconds = 10
job_template {
metadata {}
spec {
template {
metadata {}
spec {
container {
name = "hello"
image = "busybox"
command = ["/bin/sh", "-c", "date; echo Hello from the Kubernetes cluster"]
}
}
}
}
}
}
}
Explanation:
- Before: No explicit start-delay deadline is set. Review whether late execution is acceptable.
- After: A start deadline of 10 seconds after the scheduled time is set. It does not terminate a running Job after 10 seconds.