Choose Kubernetes finished-Job TTL before the evidence expires

Bottom line: Choose how long a completed Job must remain available for review before relying on automatic cleanup. Resolve the evidence requirement before expiry, rather than treating an accepted late configuration change as a recovery mechanism.

Source fact: documented behavior

The Automatic Cleanup for Finished Jobs documentation is the primary reference.

The Job TTL timer starts when its status becomes Complete or Failed, and expiry makes the Job eligible for cascading deletion of its dependents. Extending an already expired TTL does not guarantee that Kubernetes will retain the Job, even if the API update succeeds. The controller honors lifecycle guarantees such as finalizers, and its timestamp-based decision is sensitive to clock skew. The source labels the mechanism stable since Kubernetes 1.23.

What the source does not establish

This article concerns finished Job objects and their cleanup eligibility. It does not define business retention, recover removed evidence or replace an application-data preservation process. The configured TTL and the time at which cleanup is observed should be recorded separately; neither proves that a reviewer has retained the needed diagnostic material.

Applicability questions

• What completion or failure evidence must be reviewed before cleanup?
• Who owns the required post-finish observation window?
• Where will necessary logs and identifiers be preserved?
• Which finalizer or clock condition needs separate investigation?

DSE recommendation: set the review window deliberately

DSE recommends agreeing the review window with the job owner before adding ttlSecondsAfterFinished to a managed Job definition. Name the audience that needs completion evidence and the process that records it. Choose the value from that requirement instead of treating rapid cleanup as an end in itself.

Keep successful and failed runs visible in the decision. A proposed short window may be acceptable for routine confirmation yet leave too little time for a failure investigation. Review both scenarios, and establish the independent evidence destination and collection responsibility before enabling automatic removal.

For an already finished Job, record its finish condition, timestamp, configured TTL and observed object state before changing the value. If an investigation depends on that object, preserve the available evidence promptly. Do not make a late extension the sole action expected to keep it available. Escalate uncertainty about a cleanup already in progress.

Keep controller cleanup and application execution separate. Use the existing job-retry procedure for duplicated or incomplete work. Use the finalizer owner’s procedure for an outstanding cleanup condition. A longer-lived API object is not a substitute for deciding whether the application result itself is correct.

Verification and evidence

Proposed verification, not performed: prepare disposable successful and failed Jobs with an agreed short review window. Record the transition condition and observation times, collect the intended evidence, and then observe cleanup eligibility and the actual removal timeline. Identify every observation as a test result only after it is collected.

Use a separate approved case to examine a proposed extension before expiry. Treat any late-extension exercise as a test of an uncertain retention situation, not an instruction to recover a real investigation object. Retain the manifest revision, timestamps, API responses, collected evidence and outstanding finalizer information. Ask another operator to distinguish the configured deadline from what was actually retained and reviewed.

Official references

• Automatic Cleanup for Finished Jobs — Kubernetes.

Source review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.