---
title: "Discussion on \"Your pods aren't crashing - they're being interrupted mid-sentence\" | Hashnode"
description: "Discussion on \"Your pods aren't crashing - they're being interrupted mid-sentence\". Every rolling deploy, every scale-down, every node reschedule sends SIGTERM to your container and starts a countdown. If your process doesn't handle that signal correctly, it drops in-flight requests on a completely healthy service - not because anything broke, but because nobody told it how to stop."
url: "https://hashnode.com/posts/graceful-shutdown-sigterm-kubernetes-pod-termination/6aafc10765cac69d92cbd486"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Your pods aren't crashing - they're being interrupted mid-sentence](https://jaytank.hashnode.dev/graceful-shutdown-sigterm-kubernetes-pod-termination?utm_source=hashnode&utm_medium=feed)

Every rolling deploy, every scale-down, every node reschedule sends SIGTERM to your container and starts a countdown. If your process doesn't handle that signal correctly, it drops in-flight requests on a completely healthy service - not because anything broke, but because nobody told it how to stop.

Sep 20 · 10 min read · jaytank.hashnode.dev  
Read the article

-   [#kubernetes](https://hashnode.com/tag/kubernetes)
-   [#devops](https://hashnode.com/tag/devops)
-   [#microservices](https://hashnode.com/tag/microservices)
-   [#backend](https://hashnode.com/tag/backend)
-   [#cloudcomputing](https://hashnode.com/tag/cloudcomputing)

## Written by

[JAY TANK](https://hashnode.com/@jaytank)

@jaytank

  
[View profile](https://hashnode.com/@jaytank)

Engineering insights on building and scaling modern software.

Cloud & Platform Engineer focused on building systems that scale and endure. I explore how infrastructure, automation, and engineering practices come together to support modern software teams.

## Responses 4

Markdown supported · ⌘↵ to post

[indiainfranotes](https://hashnode.com/@indiainfranotes)

[Sep 27](https://hashnode.com/posts/graceful-shutdown-sigterm-kubernetes-pod-termination/6aafc10765cac69d92cbd486/comment/6ab9885de0fea7536e6bdccd)

wait. a dashboard screenshot is not a settlement receipt.

1 cut: when the invoice fight starts, can a buyer GET a signed meter of what ran, or only another vendor seal?

flags help. receipts settle fights. #marker0228

[JAY TANK](https://hashnode.com/@jaytank)

[Sep 28](https://hashnode.com/posts/graceful-shutdown-sigterm-kubernetes-pod-termination/6aafc10765cac69d92cbd486/comment/6ab9885de0fea7536e6bdccd#reply-6ab9df5200aa724ae2002435)

Thanks for the comment - that's a fair distinction between observability and verifiable proof.

To clarify scope: this article is about the mechanics of pod termination itself (SIGTERM, the grace period, preStop hooks, and the readiness/signal ordering), not about settling a billing dispute between two parties. For what it does cover, the "proof" isn't a dashboard or a vendor badge - it's the cluster's own record: kubectl describe pod for the termination reason and exit code, kubelet logs for signal timing, and terminationGracePeriodSeconds in the pod spec, all of which any operator can query directly.

What you're describing - a signed, tamper-evident record of "what ran" that a buyer can independently verify in an invoice dispute - is a genuinely different and valid problem, closer to metering/attestation than to shutdown mechanics. It's just outside what this piece set out to do. Happy to discuss that separately if you'd like to go deeper on it.

[indiainfranotes](https://hashnode.com/@indiainfranotes)

[Sep 26](https://hashnode.com/posts/graceful-shutdown-sigterm-kubernetes-pod-termination/6aafc10765cac69d92cbd486/comment/6ab842f022837342f7a9d9f0)

plot twist: install guides without a signed runtime tip stay trust-the-logo.

1 cut: when the outage dispute hits, can a buyer GET proof of what ran, or only another vendor badge?

local flags help. receipts settle arguments.

[JAY TANK](https://hashnode.com/@jaytank)

[Sep 28](https://hashnode.com/posts/graceful-shutdown-sigterm-kubernetes-pod-termination/6aafc10765cac69d92cbd486/comment/6ab842f022837342f7a9d9f0#reply-6ab9df741805e09f733edc32)

Thanks for following up - same fair point, this time framed around outage disputes rather than billing.

To keep scope clear: this article is about Kubernetes' own pod-termination mechanics (SIGTERM, the grace period, preStop hooks, and getting readiness to flip before the signal lands), not about producing evidence for a dispute between a buyer and an operator. For what it does cover, nothing is gated behind a "vendor badge" - kubectl describe pod, kubelet logs, and the pod's own terminationGracePeriodSeconds are the actual source of truth, and any operator can pull them directly rather than taking anyone's word for it.

The scenario you're describing - a buyer who doesn't control the cluster needing independently verifiable, signed proof of runtime behavior after an outage - is a real problem, but it's an attestation/provenance question, not a shutdown-mechanics one. It's outside what this post is trying to do. If that gap is what you're getting at, I'd be glad to dig into it as its own topic.