Skip to main content

Timeout Strategy

The timeout proactive resilience strategy cancels the execution if it does not complete within the specified timeout period. If the execution is canceled by the timeout strategy, it throws a TimeoutRejectedException.
It is crucial that your callback respects the cancellation token. If it does not, the callback will continue executing even after cancellation, thereby ignoring the timeout.

When to Use Timeout

Use the timeout strategy when:
  • Operations should not take longer than a specific duration
  • You want to prevent indefinite waiting for responses
  • Dealing with potentially slow or unresponsive services
  • Implementing SLA requirements with strict time limits
  • Protecting against resource exhaustion from long-running operations

Installation

Usage

Basic Timeout

Using TimeoutStrategyOptions

Dynamic Timeout

Timeout with Events

Configuration Options

TimeSpan
default:"30 seconds"
Defines a fixed period within which the delegate should complete, otherwise it will be cancelled.
Func<TimeoutGeneratorArguments, ValueTask<TimeSpan>>
default:"null"
Dynamically calculates the timeout period using runtime information. If set, the Timeout property is ignored.
Func<OnTimeoutArguments, ValueTask>
default:"null"
Invoked after the timeout occurred, just before throwing TimeoutRejectedException.

Important Considerations

Respecting Cancellation Tokens

The timeout strategy relies on co-operative cancellation. Your callbacks must honor the cancellation token:
If the cancellation token is not respected, the callback will continue executing after the timeout, and the strategy will have to wait for it to complete before throwing TimeoutRejectedException.

Best Practices

Pass the cancellation token provided by Polly to all async operations. This ensures proper timeout behavior.
  • Too short: operations fail unnecessarily
  • Too long: defeats the purpose of timeout
Consider your service’s typical response times and add buffer for variance.
Use TimeoutGenerator when different operations or contexts require different timeout values.
Place timeout inside retry to ensure each retry attempt has its own timeout:
Use OnTimeout to log or send metrics when timeouts occur. This helps identify slow operations.

Examples

HTTP Request with Timeout

Database Query with Timeout

Per-Operation Dynamic Timeouts

Timeout with Retry

Overall Timeout for Retries

OnTimeout vs Try-Catch

OnTimeout is called before the exception is thrown. This is useful when combining with retry strategy, as the retry might handle the exception. If you use try-catch, you might not catch the exception if retry succeeds on a subsequent attempt.
The timeout strategy will wait for your operation to complete before throwing TimeoutRejectedException. This defeats the purpose of the timeout. Always respect the cancellation token in your callbacks.
Yes! Use TimeoutGenerator to dynamically calculate timeouts based on context properties, operation key, or any other runtime information.
The timeout strategy wraps the incoming cancellation token with a new one. If the original token is canceled, the timeout strategy honors it without throwing TimeoutRejectedException.
It depends:
  • Inside retry (retry → timeout): Each attempt gets its own timeout
  • Outside retry (timeout → retry): The entire retry sequence must complete within the timeout
You can also use both for maximum control.