# Separate Job exit-code failures from Kubernetes disruptions > The Pod failure policy tutorial demonstrates FailJob for a known exit code and Ignore for DisruptionTarget. Review those failure classes separately from application duplicate-handling logic. - Canonical URL: https://update.dsesecurity.com/updates/separate-job-exit-code-failures-from-kubernetes-disruptions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T17:40:53+00:00 - Modified: 2026-10-29T17:41:39+00:00 - Last reviewed by DSE: 2026-10-29 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know The Pod failure policy tutorial demonstrates FailJob for a known exit code and Ignore for DisruptionTarget. Review those failure classes separately from application duplicate-handling logic. ## Potentially affected Review scope: the documented Kubernetes Job Pod failure policy examples, labeled stable since 1.31; installed cluster support and application retry safety require confirmation. ## DSE recommendation Assign an explicit policy action to a documented non-retriable application exit and a separately reviewed disruption case, then verify the Job status and retry accounting. ## Article Bottom line: Distinguish a known non-retriable application failure from an infrastructure disruption before tuning a Job retry budget. Keep failure classification separate from the application’s ability to handle repeated execution safely. ## Source fact: documented behavior The [Handling retriable and non-retriable pod failures with Pod failure policy](https://kubernetes.io/docs/tasks/job/pod-failure-policy/) documentation is the primary reference. The tutorial labels Pod failure policy stable since Kubernetes 1.31 and demonstrates a FailJob rule matching exit code 42 from a container named main. Its disruption example uses Ignore with the DisruptionTarget Pod condition to avoid incrementing the retry counter toward backoffLimit. For the FailJob example, the controller records FailureTarget when the Job is considered failed and Failed after all its Pods terminate. ## What the source does not establish The source’s example exit code is not a universal classification for applications. This article does not establish exactly-once execution, approve unlimited retries or define a production node-drain procedure. Keep duplicate-side-effect protection, workload cleanup and maintenance authorization in their own reviewed procedures. ## Applicability questions - Which application exit status is genuinely non-retriable? - Which container should the exit-code rule inspect? - Which disruption case should not consume this Job’s retry budget? - Which Job and Pod status observations will confirm the chosen action? ## DSE recommendation: document the failure classes before the policy DSE recommends a failure-class worksheet owned jointly by the application and cluster operators. For each class, record the evidence that identifies it and the intended next action. Require the application owner to define the meaning of an exit status instead of copying the tutorial’s simulated bug code into an unrelated workload. For a proposed non-retriable class, review the exact container selector and status match with the workload definition. Name who will investigate the failed Job and preserve the necessary evidence. Keep an unmatched application failure visible in the procedure so it is not mistakenly reported as a recognized permanent defect. Review disruption handling separately. Identify the approved maintenance or infrastructure case being considered, the retry-budget requirement and the observation that will classify the Pod. Do not use a failure-policy exercise as authorization to drain a shared production node. Keep the laboratory fixture and maintenance process distinct. Retain the existing application retry-safety review. Use the policy decision to describe controller handling, not to replace duplicate detection or incomplete-output recovery. Have the operator reconcile the final Job state with the specific matching condition before closing an incident, including any Pods still awaiting termination. ## Verification and evidence Proposed verification, not performed: use an isolated Job with harmless output and a deliberately chosen non-retriable test exit. Record the expected matching container, policy action and condition sequence, then inspect the actual Job and Pod statuses. In a separate authorized disruption exercise, predict the retry-counter treatment before collecting its result. Keep each case’s manifest, observed exit or condition, counter and Job state. Include an unmatched test exit to examine the intended fallback independently. Do not report a controller action as evidence that the application performed its external work only once. ## Official references - [Handling retriable and non-retriable pod failures with Pod failure policy](https://kubernetes.io/docs/tasks/job/pod-failure-policy/) — Kubernetes. Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Kubernetes — Handling retriable and non-retriable pod failures with Pod failure policy - Authority: kubernetes.io - URL: https://kubernetes.io/docs/tasks/job/pod-failure-policy/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Separate Job exit-code failures from Kubernetes disruptions,” DSE Security, https://update.dsesecurity.com/updates/separate-job-exit-code-failures-from-kubernetes-disruptions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.