An ASP.NET Core API has rising latency and timeouts but CPU is not saturated. How would you prove or disprove ThreadPool starvation?

I look for a dominant repeated pattern rather than one blocked thread. A slow database or HTTP dependency can create starvation when code waits synchronously, but the dependency latency is still part of the cause. Lock contention may show many workers waiting behind one owner, while unbounded parallel work may flood the queue even with async code. I compare healthy and unhealthy endpoints and include request volume because the same blocking path can appear harmless at low concurrency. The fix follows the evidence: async I/O end to end, shorter lock scope, bounded concurrency, backpressure, a worker boundary for CPU-heavy work, or a dependency timeout and bulkhead.