What is HttpClient's default timeout and is it safe?

HttpClient.Timeout defaults to 100,000 milliseconds, or 100 seconds, according to Microsoft's documentation. That is usually far too long for an API calling another API. Set a shorter Timeout on the shared client and use a CancellationToken for per call budgets. Only the shorter of the two limits applies.

What the API reference says

The reference page for HttpClient.Timeout gives these facts:

• The default value is 100 seconds. You can set an infinite timeout with InfiniteTimeSpan.
• Setting a value less than or equal to zero, other than InfiniteTimeSpan, throws ArgumentOutOfRangeException, as does a value above Int32.MaxValue milliseconds.
• You cannot change it after an operation has started on the instance, which throws InvalidOperationException.
• The same timeout applies to all requests from that instance. You can set different limits per request using a CancellationTokenSource, and only the shorter of the two timeouts applies.
• A DNS query may take up to 15 seconds to return or time out, so a timeout below 15 seconds can still take 15 seconds or more to be reported if a host name needs resolving.

Why 100 seconds is risky in a service

Picture a request handler that makes one downstream call per incoming request. If the downstream is slow and your timeout is 100 seconds, every request pins a thread or task, a connection and memory for 100 seconds. At modest traffic, that exhausts your capacity while the dependency is down, and the failure spreads upward. The standard fix is a budget: if the user will give up after ten seconds, the whole call chain should stop after about ten seconds.

For calls to URLs a user controls, a long timeout is also an attack lever, because someone can point your service at a server that answers slowly on purpose.

Setting limits

var client = new HttpClient(new SocketsHttpHandler
{
    PooledConnectionLifetime = TimeSpan.FromMinutes(2),
    ConnectTimeout = TimeSpan.FromSeconds(3)
})
{
    Timeout = TimeSpan.FromSeconds(10)
};

using var cts = CancellationTokenSource.CreateLinkedTokenSource(requestAborted);
cts.CancelAfter(TimeSpan.FromSeconds(5));
var resp = await client.GetAsync(url, cts.Token);

Linking the token to the incoming request's aborted token means that when a caller disconnects, your outbound work stops too. The handler timeout settings, such as the connect timeout, narrow where the time goes. The documentation for the lifetime of clients is in the HttpClient lifetime post.

What a timeout does not cover

A time limit does not cap response size. If you read a response into memory, a large body costs you even when it arrives within the deadline. Read as a stream, check content length, and set a maximum. A time limit also does not stop retries from piling on. If you add retries, use backoff, limits and a circuit breaker, and make sure the total retry time fits in the overall budget.

Steps

1. Search for HttpClient configuration and for places that never set Timeout.
2. Pick a default from your slowest valid call, not from habit.
3. Pass a CancellationToken derived from the request through every outbound call.
4. Add connect timeouts on the handler.
5. Cap response sizes when reading bodies.
6. Test by pointing a client at a deliberately slow server and confirming the failure time.

Quick check

Safeguard dependency scanning and SBOM generation cover the NuGet packages in your .NET service, and the free scan is at gold.safeguard.sh/scan.

Sources

• HttpClient.Timeout property (Microsoft Learn)
• HttpClient guidelines for .NET (Microsoft Learn)

Last reviewed: 19 October 2026.