Start here. This is the direct spoken answer to practice first.
Why this question matters
Diagnose an ASP.NET Core API that becomes slow because request threads are blocked or exhausted. It matters in real backend work because load, cancellation, retries, and dependency latency decide whether the API stays predictable under pressure. The practical angle is runtime behavior, sync-over-async, blocking calls, CPU-bound work, request queueing, and production diagnostics, tied to a concrete production decision.
I would suspect thread pool starvation when requests queue up, latency grows sharply, and many threads are blocked waiting on I/O or locks. CPU may not even be fully used. In ASP.NET Core this often comes from blocking async code with .Result or .Wait(), synchronous I/O, or long-running work inside request handlers. I would confirm with runtime counters and traces.