{
  "id": 19707606,
  "title": "Why Does My Pod Take Exactly 30 Seconds to Die?",
  "url": "https://urgent.news/2026/11/12/why-does-my-pod-take-exactly-30-seconds-to-die",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-11-12T21:05:05.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/noahcontrolplane/why-does-my-pod-take-exactly-30-seconds-to-die-h1"
  },
  "original_language": "en",
  "account": "When you execute kubectl delete pod, the corresponding container enters the Terminating state, which typically lasts for precisely 30 seconds. This consistent timing suggests a specific issue: the application never received the SIGTERM signal or disregarded it, leading the kubelet to resort to SIGKILL instead. The SIGKILL causes in-flight requests to be abruptly terminated, open transactions to be abandoned, and any data not flushed to be lost. This phenomenon affects every deployment, node drain, and scale-down operation.\n\nAccording to Kubernetes guidelines, the expected process is as follows:\n1. Execute kubectl delete pod.\n2. kubelet initiates preStop hooks, if defined.\n3. SIGTERM is sent to process ID 1 within each container.\n4. If the application handles SIGTERM, it finishes any ongoing tasks, exits with a status code of 0, and the container cleanup proceeds.\n5. If the application ignores SIGTERM, kubelet will eventually issue SIGKILL, resulting in the premature termination of the pod and its associated data loss.\n\nThere are three common causes for this issue:\n1. PID 1 is a shell, not your application. For instance, using CMD npm start creates a shell that wraps your command, intercepting SIGTERM signals and thereby failing to pass them to your application.\n2. Your application itself is running as PID 1 but lacks a signal handler. In this scenario, the operating system does not apply the default action for signals that PID 1 has not explicitly handled. Thus, an application designed to shut down properly on a local machine will ignore SIGTERM inside a container, leading to a SIGKILL.\n3. The application exists as PID 1 but fails to handle SIGTERM. Although this scenario is less common, the application will not respond to the termination signal and will be forcibly terminated by the kubelet.\n\nTo resolve these issues, several strategies can be employed:\n1. Use the exec form and run the binary directly, bypassing the shell. For example, CMD [node, server.js].\n2. Handle SIGTERM explicitly within the application, allowing it to gracefully shut down by closing connections, completing in-flight requests, and exiting with a status code of 0. This can be achieved using Node.js, Python, or Go, as demonstrated in the provided examples.\n3. Alternatively, place a minimal init process such as tini or dumb-init in front of your application. These processes act as PID 1, forward signals to your application, and manage zombie processes. While Docker provides a built-in init mechanism with --init flag, Kubernetes does not, necessitating its inclusion in the container image.\n\nTo verify if your pod configuration is the root cause, you can execute kubectl exec [pod] -- cat /proc/1/cmdline | tr \\0, which will display the command line used to start the container. If the output indicates the use of /bin/sh -c or npm, you have identified the source of your 30-second pod lifecycle. Subsequently, testing the deletion process with the command time kubectl delete pod [pod] will provide insight into the duration and effectiveness of the implemented fixes.",
  "summary": "You run kubectl delete pod , and the pod sits in Terminating . You count. It disappears at almost exactly 30 seconds, every time. Thirty seconds is Kubernetes' default terminationGracePeriodSeconds . If your pod reliably takes the whole thing, it almost always means one thing: your app never received SIGTERM, or ignored it, and the kubelet had to SIGKILL it. SIGKILL means in-flight requests got…",
  "key_points": [
    "When deleting a pod, kubelet enters Terminating state lasting 30 seconds.",
    "Application fails to handle SIGTERM, leading to SIGKILL and data loss.",
    "Solutions include running binary directly, handling SIGTERM, or using init process."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}