Context
A missing scheduled task can mean it never started, it was intentionally skipped, or its finished Job has already been cleaned up. CronJob concurrency policy controls overlapping Jobs created by that CronJob. Job TTL controls when completed or failed Job objects become eligible for deletion. Neither setting proves whether the business operation happened.
Prerequisites are the CronJob name, namespace, expected schedule, application completion evidence, and access to Job events and centralized logs. Check the cluster's supported time-zone configuration and record the relevant time zone when comparing schedules. Avoid starting an extra copy of a business task simply to test whether scheduling works.
1. Read the schedule and active execution state
kubectl -n processing get cronjob statement-export -o yaml
kubectl -n processing describe cronjob statement-export
kubectl -n processing get jobs --sort-by=.metadata.creationTimestamp
The workload name is illustrative. Inspect suspend, concurrencyPolicy, startingDeadlineSeconds, active references, and recent scheduling times. Compare the actual Job owner references with the CronJob. Another CronJob or a manually created Job can run the same program without being governed by this CronJob's concurrency setting.
2. Interpret overlap policy precisely
Allow permits overlap. Forbid can skip a new run when the previous Job is still active. Replace replaces the active Job with a new one. These are execution-policy choices, not equivalent ways to obtain one guaranteed successful business result.
For an explicitly illustrative example, statement-export is scheduled frequently, but one run lasts longer than the interval. With Forbid, the next scheduled execution may be skipped while the old Job remains active. Increasing log retention will not cause that skipped run to appear. Investigate why the existing execution has not completed and whether the application's intended schedule tolerates this behavior.
3. Check cleanup independently
Inspect the relevant Job's spec and conditions, or retrieve its saved manifest if it has been removed. Job TTL begins after the Job reaches a finished condition, and cascading cleanup can remove dependent Pods. CronJob history limits also affect retained finished Jobs.
kubectl -n processing describe job statement-export-example
kubectl -n processing get job statement-export-example -o yaml
A short ttlSecondsAfterFinished can erase the Kubernetes objects before an operator investigates. Centralized logs and external completion records should outlive the diagnostic window. Job-object retention is useful operational evidence, but it is not a durable audit record of business effects.
Use the right explanation for absent evidence
| Observation | Likely boundary | Next check |
|---|---|---|
| Active Job spans later schedules | Concurrency | Forbid/Replace policy and application duration |
| CronJob is suspended | Scheduling intentionally stopped | Owner and maintenance record |
| Finished Job disappears | Cleanup | TTL and history limits |
| Job says Complete but output is absent | Application semantics | Output destination and task-level verification |
Even a correctly configured CronJob needs an application that can tolerate retries or duplicate scheduling. Kubernetes scheduling is not a substitute for idempotency, transaction boundaries, or business reconciliation. Define what uniquely identifies an intended execution and how an operator checks its outcome before rerunning it.
Correct the policy and verify safely
Review changes to concurrency, deadlines, or retention with the task owner. A policy change should reflect acceptable overlap and recovery behavior. Validate a harmless representative task in a test namespace, including an intentionally long-running execution and a finished Job eligible for cleanup.
Maintain an SOP with schedule, time zone, maximum expected duration, overlap decision, retry procedure, and durable completion evidence. Monitor overdue active Jobs and missing business outputs separately. Retain enough logs to explain both skipped schedules and removed objects, so cleanup does not turn a diagnosable failure into guesswork.
Explore Clouvenix containers kubernetes for implementation and operational handover.