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.
\nThe Automatic Cleanup for Finished Jobs documentation is the primary reference.
\nThe 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.
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.
\nDSE 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.
\nFor 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.
\nKeep 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.
\nProposed 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.
\nUse 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.
\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: documented behavior\nThe Automatic Cleanup for Finished Jobs documentation is the primary reference.\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhat completion or failure evidence must be reviewed before cleanup?\nWho owns the required post-finish observation window?\nWhere will necessary logs and identifiers be preserved?\nWhich finalizer or clock condition needs separate investigation?\n\nDSE recommendation: set the review window deliberately\nDSE 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.\nKeep 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.\nFor 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.\nKeep 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.\nVerification and evidence\nProposed 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.\nUse 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.\nOfficial references\n\nAutomatic Cleanup for Finished Jobs — Kubernetes.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: documented behavior\n\nThe [Automatic Cleanup for Finished Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/) documentation is the primary reference.\n\nThe 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- What completion or failure evidence must be reviewed before cleanup?\n\n- Who owns the required post-finish observation window?\n\n- Where will necessary logs and identifiers be preserved?\n\n- Which finalizer or clock condition needs separate investigation?\n\n## DSE recommendation: set the review window deliberately\n\nDSE 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.\n\nKeep 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.\n\nFor 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.\n\nKeep 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.\n\n## Verification and evidence\n\nProposed 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.\n\nUse 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.\n\n## Official references\n\n- [Automatic Cleanup for Finished Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/) — Kubernetes.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/choose-kubernetes-finished-job-ttl-before-the-evidence-expires/", "url": "https://update.dsesecurity.com/updates/choose-kubernetes-finished-job-ttl-before-the-evidence-expires/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/choose-kubernetes-finished-job-ttl-before-the-evidence-expires/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Business Continuity", "item": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "ListItem", "position": 3, "name": "Choose Kubernetes finished-Job TTL before the evidence expires", "item": "https://update.dsesecurity.com/updates/choose-kubernetes-finished-job-ttl-before-the-evidence-expires/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/choose-kubernetes-finished-job-ttl-before-the-evidence-expires/#article", "identifier": "https://update.dsesecurity.com/updates/choose-kubernetes-finished-job-ttl-before-the-evidence-expires/", "url": "https://update.dsesecurity.com/updates/choose-kubernetes-finished-job-ttl-before-the-evidence-expires/", "headline": "Choose Kubernetes finished-Job TTL before the evidence expires", "description": "Finished-Job TTL creates cleanup eligibility after completion or failure. A successful extension after expiry does not guarantee that the Job will be retained.", "abstract": "Finished-Job TTL creates cleanup eligibility after completion or failure. A successful extension after expiry does not guarantee that the Job will be retained.", "articleBody": "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.\nSource fact: documented behavior\nThe Automatic Cleanup for Finished Jobs documentation is the primary reference.\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhat completion or failure evidence must be reviewed before cleanup?\nWho owns the required post-finish observation window?\nWhere will necessary logs and identifiers be preserved?\nWhich finalizer or clock condition needs separate investigation?\n\nDSE recommendation: set the review window deliberately\nDSE 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.\nKeep 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.\nFor 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.\nKeep 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.\nVerification and evidence\nProposed 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.\nUse 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.\nOfficial references\n\nAutomatic Cleanup for Finished Jobs — Kubernetes.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T00:09:53+00:00", "dateModified": "2026-10-29T00:10:35+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/choose-kubernetes-finished-job-ttl-before-the-evidence-expires/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/choose-kubernetes-finished-job-ttl-before-the-evidence-expires/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Choose Kubernetes finished-Job TTL before the evidence expires" }, "articleSection": [ "Business Continuity", "IT" ], "keywords": [ "Business Continuity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 544, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Kubernetes — Automatic Cleanup for Finished Jobs", "url": "https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/" } } ] } }