Every web application eventually encounters slow requests. A database query may take longer than expected, an external API might become unresponsive, or an expensive report could consume server resources for several minutes. If these requests continue indefinitely, they tie up threads, consume memory, reduce throughput, and negatively impact the experience for other users.
ASP.NET Core 10 provides built-in request timeout middleware that allows developers to define execution limits for HTTP requests. Instead of allowing requests to run indefinitely, applications can fail fast, free resources, and maintain responsiveness under heavy load.
In this article, you'll learn how to configure request timeouts in ASP.NET Core 10, apply different timeout policies, handle cancellation correctly, and build resilient APIs that remain responsive in production.
Why Request Timeouts Matter
The Problem with Long-Running Requests
Consider an API that generates financial reports.
Client
│
▼
ASP.NET Core API
│
▼
Business Service
│
▼
Database
If the database becomes slow, every incoming request waits for completion.
Eventually:
Request queues grow.
Thread pool resources become exhausted.
Memory usage increases.
Response times degrade.
Other users experience failures.
Timeouts prevent one slow dependency from affecting the entire application.
Understanding Request Timeouts
What Is a Request Timeout?
A request timeout defines the maximum amount of time an HTTP request is allowed to execute.
If execution exceeds the configured limit:
The request is cancelled.
Resources are released.
The client receives an appropriate response.
The server remains available for other requests.
This approach improves application resilience during dependency failures and unexpected workloads.
Configuring Request Timeout Middleware
Register request timeout services during application startup.
builder.Services.AddRequestTimeouts(options =>
{
options.DefaultPolicy = new RequestTimeoutPolicy
{
Timeout = TimeSpan.FromSeconds(30)
};
});
Enable the middleware.
var app = builder.Build();
app.UseRequestTimeouts();
Why This Configuration?
The default policy limits every request to 30 seconds unless another policy overrides it.
Rather than allowing requests to consume resources indefinitely, the middleware enforces a predictable execution window, improving application stability.
Applying Timeout Policies
Not every endpoint requires the same timeout.
A product lookup may complete within milliseconds, while generating a large report may legitimately take longer.
Create a named policy.
builder.Services.AddRequestTimeouts(options =>
{
options.AddPolicy("LongRunning",
TimeSpan.FromMinutes(2));
});
Apply it to an endpoint.
app.MapGet("/reports",
GenerateReport)
.WithRequestTimeout("LongRunning");
Why Use Multiple Policies?
Different operations consume different resources.
Applying endpoint-specific timeout policies prevents lightweight APIs from waiting unnecessarily while still allowing complex operations sufficient time to complete.
Supporting Cancellation
A timeout only helps if the application cooperates with cancellation.
app.MapGet("/orders",
async (
CancellationToken cancellationToken,
IOrderService service) =>
{
return await service
.GetOrdersAsync(cancellationToken);
});
Business service:
public async Task<IEnumerable<Order>> GetOrdersAsync(
CancellationToken cancellationToken)
{
return await _context.Orders
.ToListAsync(cancellationToken);
}
Why Pass the Cancellation Token?
When a timeout occurs, ASP.NET Core signals cancellation through the request's CancellationToken.
Passing the token to downstream services allows database queries, HTTP requests, and other asynchronous operations to stop immediately instead of continuing to consume resources after the client has disconnected.
Handling External API Calls
External services are common causes of slow requests.
var response = await httpClient.GetAsync(
"/inventory",
cancellationToken);
Why Propagate Cancellation?
If the client request times out, outgoing HTTP calls should also be cancelled.
This prevents unnecessary network activity and reduces pressure on external services.
End-to-End Implementation
Consider an inventory management platform.
Architecture:
Customer
│
▼
ASP.NET Core API
│
Request Timeout Middleware
│
Business Service
│
┌───────┴───────────┐
▼ ▼
SQL Database External Inventory API
Workflow:
A client requests inventory information.
The timeout middleware starts tracking request duration.
The business service queries the database.
Additional inventory information is requested from an external API.
If processing completes within the configured timeout, the response is returned.
If the timeout expires, the request is cancelled.
Database queries and HTTP requests receive the cancellation token and stop execution.
Resources are released for other incoming requests.
This approach prevents slow dependencies from reducing overall application responsiveness.
Request Timeout vs HttpClient Timeout
| Feature | Request Timeout | HttpClient Timeout |
|---|---|---|
| Scope | Entire HTTP request | Outgoing HTTP request |
| Configured In | ASP.NET Core | HttpClient |
| Protects | Server resources | External API calls |
| Uses Cancellation Token | Yes | Yes |
| Best For | Web applications | Service-to-service communication |
These mechanisms complement each other rather than replace one another.
Best Practices
Define realistic timeout values.
Create separate policies for long-running endpoints.
Pass cancellation tokens throughout the application.
Configure HttpClient timeouts appropriately.
Monitor timeout frequency.
Optimize slow database queries.
Cache expensive operations when appropriate.
Log timeout events for troubleshooting.
Review timeout policies as workloads evolve.
Common Mistakes
One common mistake is ignoring the CancellationToken. Even if a request times out, background operations may continue running unnecessarily if cancellation isn't propagated.
Another issue is configuring extremely short timeout values that interrupt legitimate business operations during normal system load.
Developers also sometimes assume request timeouts replace application optimization. Timeouts protect application stability, but slow queries, inefficient algorithms, and poorly performing external services should still be addressed.
Testing and Validation
Before deploying timeout policies, validate the following:
Normal request completion
Long-running request cancellation
Database query cancellation
External API cancellation
Multiple timeout policies
Concurrent request handling
Load testing
Timeout logging and monitoring
Testing ensures timeout policies behave predictably under both normal and failure conditions.
Performance Considerations
Timeout middleware introduces minimal overhead while helping maintain application responsiveness.
For optimal performance:
Optimize database queries before increasing timeout values.
Avoid blocking synchronous operations.
Use asynchronous APIs throughout the request pipeline.
Monitor average request duration.
Review timeout metrics regularly.
Profile endpoints with consistently high execution times.
The objective is not simply increasing timeout limits but reducing request duration whenever possible.
Security Considerations
Request timeouts contribute to application resilience but should be combined with other security controls.
Follow these recommendations:
Use rate limiting to reduce abusive traffic.
Validate request payloads early.
Protect expensive endpoints with authorization.
Monitor unusual timeout patterns.
Configure reverse proxy timeouts consistently.
Apply circuit breakers for unreliable external services.
Log repeated timeout failures for investigation.
Layered protection helps maintain availability during both operational issues and malicious traffic spikes.
Troubleshooting
Requests Always Time Out
Review database performance, external dependencies, and endpoint implementation to identify slow operations rather than simply increasing timeout values.
Cancellation Does Not Stop Processing
Verify that the request's CancellationToken is passed to every asynchronous operation, including Entity Framework queries and HttpClient requests.
Different Endpoints Require Different Limits
Create multiple named timeout policies and apply them selectively instead of relying solely on the default policy.
Timeout Errors Increase During Peak Traffic
Investigate resource utilization, database performance, and thread pool exhaustion. Frequent timeouts often indicate an underlying performance bottleneck.
Conclusion
Request timeouts are an important part of building resilient ASP.NET Core 10 applications. By limiting request execution time, propagating cancellation tokens, and applying endpoint-specific timeout policies, developers can prevent slow operations from consuming valuable server resources. Combined with performance optimization, proper monitoring, and resilient dependency handling, request timeout middleware helps maintain responsive and reliable applications under both normal workloads and unexpected production conditions.

Jasen FiciPosted Aug 6, 2026, 12:58 PM
We shared this with DotNetNews readers here: https://dotnetnews.co/archive/the-net-news-daily-issue-513/