One service restarts unpredictably; another is slow with low CPU. Both run on Kubernetes. What are you looking at?

The two symptoms map to the two resource behaviours

Unpredictable restarts → OOM kill. Memory is incompressible: a container exceeding its memory limit is killed and restarted. The restart looks unexplained because the application logs end mid-work with no error — the process was terminated, not failed.

Slow with low CPU → CPU throttling. CPU is compressible: a container exceeding its CPU limit is throttled rather than killed. It keeps running, slowly. The reported CPU usage is at the limit, which can look low in absolute terms, and there is no error anywhere.

How to confirm each

OOM: check the pod's last termination reason (OOMKilled) and the restart count. Node-level kernel logs confirm it. Then look at whether the limit is wrong or the application genuinely leaks.

Throttling: the container CPU throttling metric — throttled periods as a share of total periods. This is the diagnostic, and it is absent from most default dashboards, which is why this symptom is routinely misattributed to a slow dependency.

The fixes

For the OOM-killed service: determine whether the limit is too low or the memory use is unbounded. For JVM and .NET workloads, check that the runtime is container-aware and that heap settings respect the limit — a runtime sizing its heap from the host's memory rather than the cgroup limit will be killed reliably. Set memory requests equal to limits so scheduling reflects real need.

For the throttled service: raise or remove the CPU limit. The widely-argued position is that CPU limits often cause more harm than good — throttling a container when the node has idle CPU costs latency for no benefit — while CPU requests remain essential for scheduling. The counter-argument is fairness in multi-tenant clusters, so the decision should be explicit rather than defaulted.

The wider observation

Requests set far above real usage are the largest source of wasted cluster spend, because requests reserve capacity whether used or not. The pair of numbers deserves deliberate setting from measured usage, not the framework default that was copied from an example.

What a strong answer adds

Noting that both symptoms are invisible to application-level monitoring and visible only in platform metrics — which is why a service running on Kubernetes needs container resource metrics on the same dashboard as its golden signals, or these two failures get diagnosed as something else for hours.