How can I diagnose intermittent connection pool exhaustion in EF Core when using connection resiliency retry strategies?

Likely explanation

When EF Core’s connection resiliency (execution strategy) is enabled, transient faults trigger automatic retries. This masking can make it look like the failures are due to temporary glitches when, in fact, the underlying ADO.NET connection pool may be exhausted and connections are not being returned to the pool.

Confirmed facts from the documentation

• EF Core’s execution strategy automatically retries failed database commands (1).
• ADO.NET connection pooling has configurable limits; exceeding those limits results in rejected connections or degraded performance (2).
• EF Core simple logging can emit connection‑level events such as ConnectionOpened and ConnectionClosed under the Microsoft.EntityFrameworkCore.Database.Connection category (3).

Steps to diagnose pool exhaustion while keeping resiliency active

1. Enable EF Core logging for the Database.Connection category (and optionally for Command/Transaction if you want more context). Example in OnConfiguring:

optionsBuilder.LogTo(
    Console.WriteLine,
    new[] { Microsoft.EntityFrameworkCore.DbLoggerCategory.Database.Name },
    Microsoft.EntityFrameworkCore.LogLevel.Information);

2. Add a filter to capture only the connection opened/closed events (these have the IDs RelationalEventId.ConnectionOpened and RelationalEventId.ConnectionClosed). This lets you see each time a connection is taken from or returned to the pool.
3. Run the application under load and watch the log output. Look for a pattern where many ConnectionOpened lines appear without a matching ConnectionClosed for the same connection ID, or where the number of concurrent opens steadily climbs and plateaus at the pool’s maximum size.
4. If you see the count of open connections hitting the configured Max Pool Size (default 100) and no further ConnectionClosed events, the pool is exhausted. The execution strategy will then retry the command, which will appear in the logs as repeated CommandExecuted entries followed by another ConnectionOpened attempt.
5. Correlate these observations with any exceptions that surface despite retries (e.g., TimeoutException or SqlException with a message about pool limits). Those exceptions confirm that the retry strategy could not recover because the pool was truly exhausted.

Missing diagnostic detail that would change the recommendation

Could you confirm whether the observed failures include exceptions that explicitly indicate pool exhaustion (for example, a TimeoutException or SqlException whose message mentions pool limits or “max pool size reached”)? Knowing this would let us focus on adjusting pool size versus investigating other transient faults.