# Budget PreStop work inside the Pod termination grace period > The documented termination budget covers both PreStop execution and normal container shutdown. Allocate and test those stages together rather than assuming the hook adds extra time. - Canonical URL: https://update.dsesecurity.com/updates/budget-prestop-work-inside-the-pod-termination-grace-period/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T00:09:49+00:00 - Modified: 2026-10-29T00:10:35+00:00 - Last reviewed by DSE: 2026-10-28 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know The documented termination budget covers both PreStop execution and normal container shutdown. Allocate and test those stages together rather than assuming the hook adds extra time. ## Potentially affected Review scope: documented Kubernetes PreStop timing for an ordinary container; sidecar ordering, installed runtime and application shutdown need separate assessment. ## DSE recommendation Write a shared termination budget for the hook and application, then measure both stages in a controlled workload exercise. ## Article Bottom line: Give hook work and application shutdown one explicit time budget. Review what must happen before the stop signal and what must happen afterward, rather than approving each stage independently against the full grace period. ## Source fact: documented behavior The [Container Lifecycle Hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) documentation is the primary reference. PreStop must complete before the TERM signal is sent, while the Pod grace-period countdown starts before the hook runs. The grace period covers both PreStop execution and normal container stopping; the guide illustrates a combined duration exceeding the budget. ## What the source does not establish This article concerns the documented shared timing budget, not an application-specific safe shutdown guarantee or a sidecar ordering plan. It does not establish how long a real hook or application will take. Define the workload result and safe test conditions before exercising any termination scenario. ## Applicability questions - What work is assigned to the hook rather than application shutdown? - What total termination budget is configured for the workload? - Which stage timestamps and application observations can be collected? - What is the stop condition if the approved exercise threatens unrelated work? ## DSE recommendation: review the whole termination sequence DSE recommends a short timeline with the grace-period start, hook start and finish, stop signal, and application completion. Put the intended work beneath each stage. Have the workload owner identify which work is necessary and which can be moved out of the termination path. Allocate the proposed budget across the stages before tuning values. Use measured representative behavior when it is available, and label unmeasured allowances as estimates. Do not add two independently accepted stage limits without reconciling their combined duration and the margin needed for the intended workload. Review the hook implementation for a clear completion condition and a bounded failure path. Keep an indefinitely waiting dependency out of an accepted design unless its consequences have been explicitly resolved. Assess what evidence the application owner needs to confirm its own shutdown work; the hook’s completion marker should not stand in for that application result. Keep this review distinct from restartable-sidecar order. Use the relevant sidecar runbook when that mechanism is involved, and connect its observations to the timeline without replacing this shared-budget calculation. Preserve the configuration revision and the assumptions that justified each allowance for later changes. ## Verification and evidence Proposed verification, not performed: prepare a harmless disposable workload with observable hook and application milestones. For a proposed 60-second budget, compare a planned 40-second hook plus 10-second application allowance with a planned 55-second hook plus 10-second allowance. These are exercise inputs, not measured performance or customer requirements. Collect the actual stage timings and termination result under the approved plan. Compare the observations with the documented shared-budget rule and investigate any discrepancy before changing the production allowance. Retain the hook revision, workload configuration, timestamps and application completion evidence. Ask a second operator to distinguish the arithmetic of the planned case from the behavior that was actually observed. ## Official references - [Container Lifecycle Hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) — Kubernetes. Source review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Kubernetes — Container Lifecycle Hooks - Authority: kubernetes.io - URL: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Budget PreStop work inside the Pod termination grace period,” DSE Security, https://update.dsesecurity.com/updates/budget-prestop-work-inside-the-pod-termination-grace-period/ 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.