How would you set and reason about timeouts for downstream dependencies in an ASP.NET Core API?

In production I use dependency-specific budgets rather than one arbitrary global number. Connection establishment, command execution, and total operation time can fail differently, and a queue or batch job may legitimately use a different budget from an interactive request. The timeout path maps to an honest API response and records dependency name, elapsed time, attempt count, remaining request budget, and whether the outcome is known. Concurrency limits and circuit breakers contain a dependency that is timing out at scale; merely shortening the timer can still create a flood of abandoned work. Load and failure tests verify that timeout and retry policy reduce resource saturation, and dashboards track latency percentiles, timeout rate, pool pressure, and retry-added traffic.