Hi All,
I am currently hosting a website in a Kubernetes environment and am experiencing one specific issue where the website pods intermittently stop responding to HTTP requests even though the pods themselves continue to appear as running. Under normal conditions, the website loads correctly and users can access the expected pages without noticeable delays, but occasionally requests to the website begin taking much longer than normal and eventually remain pending. What makes the situation confusing is that Kubernetes does not immediately show the affected pod as failed or terminated; from the basic pod status, it can still appear to be running normally. The problem is therefore not simply that the application crashes and Kubernetes restarts it. Instead, the application inside the pod seems to reach a state where it is no longer responding properly to incoming HTTP requests while the Kubernetes workload itself remains present. The issue is intermittent, so the same deployment can operate normally for an extended period before one or more requests become stuck. A restart of the affected pod restores normal website access, but I would like to understand why this happens in the first place rather than treating pod restarts as the permanent solution. I am specifically trying to diagnose the point at which a running website pod stops serving requests correctly while Kubernetes still considers the container to be alive.
The website is deployed through a Kubernetes Deployment, and the application is exposed through the normal Kubernetes networking components so that external users can reach it. Most of the time, requests are handled normally, and there is no obvious indication that the application has completely crashed. The issue becomes visible when a request remains pending or takes significantly longer than expected, while other Kubernetes resources continue to report apparently healthy states. In some cases, restarting the affected pod immediately restores normal behavior, which suggests that something inside the running container may be getting into an unhealthy state over time. I have been trying to determine whether this is related to how the application handles connections, request workers, or other resources inside the container, but I do not want to assume the cause without evidence. I am particularly interested in understanding how Kubernetes determines whether a pod is actually healthy enough to receive traffic. A container being in the Running state does not necessarily seem to mean that the website application is capable of successfully handling HTTP requests at that exact moment. This makes me wonder whether I should be using a Kubernetes readiness probe that checks an actual application endpoint rather than relying only on the container process remaining alive.
I have already tried observing the affected workload with the standard Kubernetes status and log commands when the website is behaving normally and when the problem occurs. The application logs do not always show an obvious fatal error immediately before the requests become unresponsive, which makes the issue difficult to correlate with a specific application exception. The pod can continue producing normal-looking output while an HTTP request from outside the cluster remains pending. I have also compared the behavior before and after restarting the pod, and the fact that a fresh pod begins responding normally again makes me think that some runtime state may be accumulating or becoming blocked during the pod’s lifetime. I am not sure whether Kubernetes itself should detect this condition automatically or whether that responsibility belongs to the application’s health endpoint and readiness configuration. I have considered increasing resource limits, changing restart behavior, or modifying the deployment configuration, but I would prefer to first determine whether the problem is actually caused by resource exhaustion or by an application process that is alive but no longer capable of processing requests. If there are particular Kubernetes commands or diagnostics that would help capture the state of a pod at the exact moment it stops responding, I would appreciate recommendations on what information is most useful.
One area I am particularly interested in is the distinction between liveness and readiness for this situation. At the moment, Kubernetes can see that the container process is still running, but that does not necessarily tell me whether the website is actually able to serve traffic. If the application becomes stuck internally while its main process remains alive, a basic liveness check may continue passing even though users are experiencing failed or hanging requests. I am wondering whether a readiness probe that makes a lightweight HTTP request to the application’s own health endpoint would allow Kubernetes to temporarily remove an unhealthy pod from service while leaving the container available for debugging. At the same time, I do not want to configure an overly aggressive probe that causes unnecessary restarts whenever the application experiences a brief delay. I would like to understand what is considered a sensible readiness and liveness configuration for a web application where the main symptom is that the process remains alive but stops responding correctly. I am also interested in whether a probe failure would actually address the underlying problem or simply make Kubernetes react more quickly to an application condition that still needs to be diagnosed. My goal is to use Kubernetes health mechanisms correctly while also identifying why the website application enters this unresponsive state.
For troubleshooting, I am trying to capture information from the moment the website is healthy until the point where requests begin hanging. I would like to compare the pod’s resource usage, container logs, probe results, restart count, and application response behavior between those two states. I am also considering whether checking the endpoints associated with the Service would help determine whether traffic is still being directed to a pod that is no longer capable of serving requests. If Kubernetes believes the pod is ready while the application is effectively stuck, that could explain why requests continue reaching it instead of being redirected to another healthy replica. I would like to know whether there is a recommended diagnostic sequence for determining whether the failure is at the application process, readiness state, Service routing, or another Kubernetes layer. I am deliberately trying to keep the investigation focused on this one symptom rather than changing several networking and deployment settings simultaneously. Ideally, I would like to reproduce the problem, collect the pod’s state while it is still running but not responding, and then determine what Kubernetes sees compared with what an actual HTTP request sees. Any guidance on useful kubectl output, probe configuration, or debugging techniques for a running but unresponsive web pod would be very helpful.
Has anyone encountered a Kubernetes-hosted website where the application occasionally stops responding to HTTP requests while the affected pod continues to show as Running, and restarting that pod temporarily restores normal behavior? I am mainly looking for advice on how to identify whether Kubernetes is correctly detecting the application’s health and whether readiness or liveness probes should be used differently in this situation. The important part is that the container does not necessarily crash, but the website inside it can become unresponsive enough that external HTTP requests remain pending or take far longer than normal. I would like to understand how to capture the state of the pod during the failure and determine why Kubernetes continues treating it as available. If there is a recommended pattern for designing health endpoints and configuring probes for this type of web application, I would appreciate examples or guidance on what should be checked first. I am hoping to find the underlying reason the application becomes unresponsive rather than simply increasing restart frequency, because the current pod restart workaround only restores service temporarily. Any suggestions for tracing the transition from a healthy, responding pod to a running but unresponsive pod would be very useful. Sorry for long post!