iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Every completed Kubernetes email Job needs a defined cleanup owner. For a standalone Job, set .spec.ttlSecondsAfterFinished to keep the finished run for a chosen interval before it becomes eligible for automatic deletion. For a CronJob, set the successful- and failed-run history limits on the CronJob. Retain enough Job and Pod history—or export logs elsewhere—to investigate a failed send before cleanup removes the in-cluster evidence.
First identify which resource creates the email run
A Kubernetes Job runs work to completion. A finished Job and its Pods commonly remain in the cluster so operators can check status and inspect logs. The TTL-after-finished controller does not automatically remove an unmanaged standalone Job unless a TTL is configured; someone must own its retention policy or delete it explicitly. See the Kubernetes Job documentation.
A workload that runs on a schedule is not necessarily enough to identify its owner. Check the live resource, its owner references, and the manifests that create it. If a CronJob controls the Jobs, configure history limits on the CronJob. If a process creates standalone Jobs, configure each Job’s TTL or provide another deliberate cleanup mechanism.
Choose time-based or count-based retention
| Mechanism | Configure on | Retention basis | Success and failure handling |
|---|---|---|---|
.spec.ttlSecondsAfterFinished |
Standalone Job | Time since the Job’s terminal condition is recorded | Applies to Jobs marked Complete or Failed; one TTL setting covers either outcome |
.spec.successfulJobsHistoryLimit and .spec.failedJobsHistoryLimit |
CronJob | Number of finished Jobs retained | Separate limits for successful and failed runs; documented defaults are 3 successful and 1 failed Job |
The TTL mechanism is documented as stable since Kubernetes v1.23. The figures for CronJob history limits are documented defaults, not guarantees about how long any run remains available: a count limit retains a number of runs, so the elapsed time represented by that history varies with the schedule and run creation.
#1 Best Overall
Configure a standalone Job’s TTL
Add ttlSecondsAfterFinished under the Job’s spec. Choose the value based on how long operators need to inspect failed sends, application output, and retry behavior. For example, a value of 86400 represents a 24-hour retention interval; it is an example configuration, not a Kubernetes default.
apiVersion: batch/v1
kind: Job
metadata:
name: email-send
spec:
ttlSecondsAfterFinished: 86400
template:
spec:
restartPolicy: Never
containers:
- name: sender
image: example.invalid/email-senderReplace the example image with the image used by your workload. The TTL setting does not change how the email is sent; it controls when a finished Job becomes eligible for cleanup.
When the Job is marked Complete or Failed, its TTL countdown begins from the timestamp of that status condition. After the interval, the Job becomes eligible for cascading deletion, including dependent objects such as its Pods. This is not a promise that deletion occurs at the exact second the interval expires. Kubernetes honors lifecycle guarantees such as finalizers, as described in the TTL-after-finished documentation and the Finalizers documentation.
Set history limits for CronJob-created runs
For scheduled email work, configure retention on the CronJob rather than treating each generated Job as an unrelated standalone run. The current Kubernetes documentation specifies defaults of three successful finished Jobs and one failed finished Job. Set explicit values if those defaults do not leave enough failure history or retain more successful runs than you need.
Rank #3
apiVersion: batch/v1
kind: CronJob
metadata:
name: scheduled-email
spec:
schedule: "0 * * * *"
successfulJobsHistoryLimit: 3
failedJobsHistoryLimit: 5
jobTemplate:
spec:
template:
spec:
restartPolicy: Never
containers:
- name: sender
image: example.invalid/email-senderThis example retains up to three successful Jobs and five failed Jobs. Set either history limit to 0 to retain none of that class. History limits are counts, not time windows: for example, a high-frequency schedule can replace older evidence sooner than a less frequent schedule. Consult the Kubernetes CronJob documentation for the current behavior and configuration details.
Account for when cleanup timing starts
On Kubernetes v1.31 and later, the Job controller delays the terminal Complete or Failed condition until all Pods for that Job have terminated. Because TTL timing starts from the recorded terminal condition, this can affect when a TTL-based cleanup becomes eligible compared with earlier versions. Check the cluster version when calculating how long a finished run may remain.
TTL cleanup depends on timestamps stored in Job objects and is sensitive to clock skew. If the TTL has already expired, increasing its value later does not guarantee that the Job will be retained, even if the update is accepted. Configure retention before runs finish rather than relying on a last-minute extension.
Preserve evidence needed to diagnose failed sends
Deleting a Job cascades to dependent objects, including Pods. Once those objects are removed, their in-cluster status and logs may no longer be available. Decide how long the team needs to investigate delivery failures before choosing a short TTL or low CronJob history limits. If logs must outlive the Job, send them to an external logging system before cleanup; that preserves output but does not itself delete Kubernetes Jobs.
- Keep failed Jobs long enough to inspect their status, Pod events, and application output.
- Use a separate successful-run limit if routine successes need less investigation time than failures.
- For rules based on labels or Job status beyond a fixed TTL, the Kubernetes TTL documentation identifies admission webhooks or a custom controller as possible approaches.
Do not mistake cleanup for duplicate-send protection
Kubernetes documents CronJob scheduling as approximate: under some circumstances, a CronJob can create multiple Jobs or miss a Job. Email workloads should therefore be designed to tolerate repeated execution—for example, by using application-level idempotency or deduplication appropriate to the sending system. Cleanup settings only control retained Kubernetes objects; they do not prevent a duplicate email from being sent.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
