Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To add HTTP retries and a circuit breaker in .NET 10, register a named or typed HttpClient with AddHttpClient, then add Microsoft’s Microsoft.Extensions.Http.Resilience standard handler. Its defaults are a starting configuration, not a universal production policy: in particular, it retries all HTTP methods unless you disable retries for unsafe ones. The package also provides resilience telemetry enrichment, but that is not a complete distributed-tracing or exporter setup.
Which .NET resilience package should you use?
For outbound HttpClient calls, Microsoft documents Microsoft.Extensions.Http.Resilience. For resilience pipelines that are not specific to HTTP clients, it documents Microsoft.Extensions.Resilience. Both are built on Polly. Microsoft marks the older Microsoft.Extensions.Http.Polly package as deprecated. These package recommendations are from Microsoft Learn’s .NET resilience guidance, last updated February 24, 2026.
Install the HTTP package in your .NET 10 project with:
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →dotnet add package Microsoft.Extensions.Http.ResilienceThe Microsoft API reference search listing available on October 7, 2026 identified version 10.9.0 and carried a prerelease warning. Check the package’s current release status and API documentation for your project before pinning a version; the configuration figures below are documented standard-handler defaults, not benchmark results.
#1 Best Overall
How do you add a standard resilience handler?
Register a named client and attach one standard handler. The same handler can be added to a typed client registered with AddHttpClient<TClient>.
using Microsoft.Extensions.Http.Resilience;
var builder = Host.CreateApplicationBuilder(args);
builder.Services
.AddHttpClient("catalog", client =>
{
client.BaseAddress = new Uri("https://api.example.test/");
})
.AddStandardResilienceHandler();
var app = builder.Build();Replace the example host with the actual API origin. The example demonstrates registration only; it does not configure authentication, request headers, dependency injection for a consuming service, or telemetry exporters.
What the standard handler does
Microsoft documents the handler’s strategy order as rate limiting, total request timeout, retry, circuit breaker, and per-attempt timeout. In the defaults documented by Microsoft Learn in 2026, the rate limiter’s exact limit is not stated in the cited summary; the other settings are:
| Strategy or setting | Documented standard-handler default | What it controls |
|---|---|---|
| Total request timeout | 30 seconds (Microsoft Learn, 2026) | Maximum time budget for the overall operation, including retries and delays. |
| Retry | 3 maximum retries; exponential backoff, jitter enabled, 2-second delay (Microsoft Learn, 2026) | Sequentially repeats an eligible request after a transient failure. The documented delay is a base delay; exponential backoff and jitter affect actual spacing. |
| Circuit breaker | 10% failure ratio; minimum throughput 100; 30-second sampling duration; 5-second break duration (Microsoft Learn, 2026) | Evaluates failures in a sampling window and temporarily blocks calls when the configured threshold is met. |
| Per-attempt timeout | 10 seconds (Microsoft Learn, 2026) | Limits the duration of an individual attempt. |
| Rate limiting | Exact default limit not stated in the cited Microsoft Learn summary. | Restricts concurrent or incoming work according to the configured limiter. |
The total timeout wraps retrying, so the overall time limit can end the operation before all retry attempts and delays are used. A per-attempt timeout, by contrast, bounds one try. Treat the documented values as defaults only: a 30-second budget, for example, may be too long for a latency-sensitive request or too short for a slow dependency. Select limits based on the caller’s deadline, dependency behavior, and the consequences of delayed or rejected work.
When is it safe to retry an HTTP request?
The standard handler retries all HTTP methods by default. That can be unsafe: if a POST creates a database record and the server completes the write but the response is lost, retrying may create a duplicate. Retry only when repeating the operation is safe for the API and the application.
Disable retries for unsafe methods
If the client should retry safe methods but not unsafe ones, use the documented helper when configuring the standard handler:
builder.Services
.AddHttpClient("catalog")
.AddStandardResilienceHandler(options =>
{
options.Retry.DisableForUnsafeHttpMethods();
});If only a particular method must be excluded, Microsoft also documents disabling retries for selected methods with DisableFor, for example:
builder.Services
.AddHttpClient("catalog")
.AddStandardResilienceHandler(options =>
{
options.Retry.DisableFor(HttpMethod.Post);
});For an operation that must be safely repeatable, an API may support an idempotency-key design. The key’s meaning, scope, retention, and duplicate-response behavior must be agreed between client and API; the Microsoft guidance cited here does not prescribe a particular protocol.
What failures are eligible?
Microsoft’s documented standard-handler retry and circuit-breaker predicates include HTTP 500 and higher, HTTP 408, HTTP 429, and exceptions including HttpRequestException and Polly’s TimeoutRejectedException. TimeoutRejectedException is distinct from the built-in .NET TimeoutException. Do not assume every exception, status code, or application-level error is retried; configure the predicate to match the dependency’s actual transient-failure contract.
How do retries, circuit breakers, timeouts, rate limits, and hedging differ?
| Mechanism | Behavior | Useful when | Main trade-off |
|---|---|---|---|
| Retry | Repeats a failed request sequentially after a delay. | A failure is likely transient and replaying the operation is safe. | Consumes additional time and can add load while a dependency is unhealthy. |
| Circuit breaker | Temporarily rejects calls after failures meet a threshold in a sampling window. | Continuing to call a failing dependency is wasteful or harmful. | Calls can be blocked during the break period even if the dependency has recovered. |
| Total request timeout | Caps the full operation, including recovery work. | The caller has an end-to-end deadline. | Can stop an operation before all configured attempts run. |
| Per-attempt timeout | Caps the duration of one try. | A single slow response should not consume the entire budget. | Short limits can cancel requests that would otherwise succeed. |
| Rate limiting | Limits work admitted or allowed concurrently. | You need to protect a service or client from excessive in-flight work. | Excess work may be queued or rejected depending on the limiter configuration. |
| Hedging | Can issue parallel attempts rather than waiting for one attempt to fail before retrying. | Latency reduction is important and the dependency can safely handle parallel requests. | Can increase concurrent load and requires careful endpoint selection and concurrency controls. |
Microsoft provides a standard hedging handler as a separate alternative to the standard resilience handler. Hedging is not simply “more retries”: parallel requests can overlap, so assess duplicate-work safety, endpoint selection, and resource limits before using it.
How should you configure retries and the circuit breaker?
Use one resilience handler per HttpClient. Microsoft advises against stacking multiple resilience handlers, which can create confusing or multiplied retry and timeout behavior. If the standard composition does not fit, use one custom AddResilienceHandler pipeline to compose the strategies you need rather than layering separate standard handlers.
Free tools Windows power users keep installed
One-click scans. No signup required.
Make the timeout budget explicit
For a customized standard handler, the relevant options include TotalRequestTimeout.Timeout and AttemptTimeout.Timeout. For example, an application can set them deliberately rather than relying on defaults:
builder.Services
.AddHttpClient("catalog")
.AddStandardResilienceHandler(options =>
{
options.Retry.DisableForUnsafeHttpMethods();
options.TotalRequestTimeout.Timeout = TimeSpan.FromSeconds(12);
options.AttemptTimeout.Timeout = TimeSpan.FromSeconds(4);
});The 12-second total and 4-second attempt values here are illustrative application choices, not Microsoft recommendations or measured performance results. A total budget must account for the time spent on each attempt and any backoff delays, and should fit within the calling operation’s own deadline.
Understand the circuit-breaker threshold
The standard handler’s documented defaults are a 10% failure ratio, minimum throughput of 100, 30-second sampling duration, and 5-second break duration (Microsoft Learn, 2026). The failure ratio is considered within a sampling window, and the minimum throughput prevents a low number of calls from being treated as a meaningful sample. When the threshold is met, the breaker opens and calls are blocked for the break duration; after that, the pipeline can allow calls again according to the breaker’s behavior.
Those numbers are defaults, not production tuning advice. A dependency with low traffic may not reach the documented minimum throughput quickly, while a high-volume dependency may reach a failure threshold rapidly. Choose the predicate, sampling period, minimum throughput, ratio, and break duration in context. In a custom pipeline, define what counts as failure deliberately; a client-side validation error or a permanent application response may not be a transient dependency failure.
How can you observe resilience behavior?
Microsoft documents AddResilienceEnricher() for enriching resilience telemetry with dimensions such as error.type, request.name, and request.dependency.name. This is resilience telemetry enrichment. It does not by itself configure distributed tracing, trace-context propagation, an exporter, or a dashboard.
Microsoft’s .NET resilience introduction shows the enrichment registration as part of telemetry setup:
builder.Services.AddOpenTelemetry()
.WithMetrics(metrics => metrics.AddResilienceEnricher());Use that registration only in a project that has the corresponding OpenTelemetry and resilience-enrichment dependencies configured. The Microsoft pages cited here document the enrichment and its dimensions, but do not provide a complete end-to-end tracing or exporter recipe. To investigate retry behavior, collect the emitted telemetry through the observability stack your application already configures and inspect the available error and dependency dimensions.
What compatibility issue should you check?
Microsoft’s HTTP resilience guidance reports a telemetry compatibility issue when Application Insights 2.22.0 or lower is registered after resilience: telemetry can be lost. The documented remedies are to upgrade to 2.23.0 or register Application Insights first. Confirm the actual package versions and registration order in your application; the guidance page was last updated February 24, 2026.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
