Recommended Free Tools
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
If an ASP.NET Core API reports Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool, the application waited for a database connection and could not get one before the connection timeout. That confirms pressure at connection checkout; it does not, by itself, tell you whether connections are leaking, queries are slow or blocked, transactions are holding connections, demand is too high, pools are fragmented, or the database has reached a limit.
Start by confirming which provider and driver are in use, then measure both the client-side pools and the database. The details and default values below are for Microsoft.Data.SqlClient unless stated otherwise. ASP.NET Core does not set one universal database-pool size, and other drivers can have different defaults and diagnostics.
What the timeout means
Microsoft documents the full exception as: System.InvalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached. The failure occurs while the application is opening or acquiring a connection, before the command can run. The connection timeout bounds how long an open can wait; it is not the SQL command execution timeout.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
A full pool is a symptom, not a root-cause diagnosis. A connection may be unavailable because it is still doing useful work, held by a transaction, stuck behind blocking, or not being returned correctly. Alternatively, the application may be asking for more simultaneous connections than the database or deployment can support.
#1 Best Overall
Separate the database connection pool from EF Core context pooling
EF Core does not implement the database connection pool. The underlying provider and driver manage database connections; EF Core generally opens a connection shortly before an operation and closes it afterward so it can return to the driver pool. Manually opening a connection changes that lifecycle: application code must close or dispose it reliably.
DbContext pooling is a separate optimization that reuses EF Core context objects. It does not increase the number of database connections available in the driver pool. Treat context reuse and connection capacity as distinct settings at distinct layers.
If you manually manage a connection while using pooled DbContext instances, restore its state before the context is reused. A context returned to its pool with an open connection or other altered connection state can cause problems for later work.
Confirm where the failure occurs before changing settings
Use the exception and stack trace to verify that the failure occurs during connection acquisition or open, rather than during command execution. Record the facts needed to interpret pool measurements and reproduce the load:
- The database provider and exact driver version.
- The effective connection-string settings, with passwords, tokens, and other secrets removed.
- The database endpoint and any identity or credential variation used to connect.
- Request concurrency, process and replica counts, and when the failures began.
- Whether connection opens, commands, readers, or transactions remain active when latency rises.
Microsoft’s SqlClient troubleshooting guide describes the pool-checkout timeout; its connection-pooling documentation defines the driver settings. Verify the behavior against the driver version actually deployed rather than assuming every ASP.NET Core provider works like SqlClient.
Measure client pool pressure and database-side causes
For Microsoft.Data.SqlClient, inspect pool activity
On .NET Core and .NET Standard, use SqlClient event counters to examine connection activity. Look at active pool groups and pools, and at active and available resources where those counters are exposed. Distinguish hard connects (physical opens) from soft connects (pool checkouts and returns). Also inspect stasis and reclaimed connections; reclaimed connections are a reason to audit code paths that did not call Close or Dispose.
For a deeper trace, use SqlClient event-source tracing only for a bounded diagnostic window. It is verbose and can capture connection metadata, so limit collection to what you need and handle the resulting trace as potentially sensitive.
Free tools Windows power users keep installed
One-click scans. No signup required.
Correlate with database evidence
Client counters show what the application and driver are doing, but not why a connection remains busy. At the database, correlate the incident window with session counts, waits, blocking, long-running work, and server resource or connection limits. A high active count with long commands points to a different remedy from a high reclaimed count or many separate pools.
Check ThreadPool starvation as a separate hypothesis
ASP.NET Core request latency can also rise when .NET ThreadPool workers are starved. That is a different pool from the database connection pool, although both problems can occur together. Microsoft’s .NET 9-and-later ThreadPool starvation tutorial uses dotnet-counters to identify likely starvation and dotnet-stack or dotnet-trace to investigate work holding threads. Do not treat a ThreadPool counter as evidence that the database pool is exhausted, or vice versa.
Find what is keeping connections unavailable
Audit disposal on every code path
Review all paths that create or acquire connections, commands, readers, and transactions. Ensure deterministic disposal still happens after exceptions, cancellation, and early returns. An open reader or command can keep its connection occupied; a missing disposal can prevent the connection from returning to the pool. With EF Core’s normal operation lifecycle, EF generally opens and closes for the operation, but manually opened connections still need explicit cleanup.
Reduce long-running or blocked work
Compare connection hold time with database command duration. Slow queries, lock waits, or other blocking keep connections busy longer, increasing the number needed to serve the same request rate. Use database wait and blocking evidence to address the operation or contention rather than treating a larger pool as the first fix.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteBound transactions, including ambient transactions
Complete or roll back transactions promptly. A long or abandoned ambient transaction can keep a connection in a transaction-specific pool subdivision after logical close; it may not be generally available until that transaction completes. Transaction-held server locks or state can also prolong the underlying database work.
Check whether connection configuration creates many pools
SqlClient pools are keyed by connection configuration and identity details. Small differences can split what appears to be one workload into multiple pools. Check for:
- Different keyword ordering or aliases in connection strings.
- Per-request, per-customer, per-user, or per-database connection strings.
- Different integrated Windows identities.
- New credential or callback objects created for each request, or frequently changing direct token strings.
- High-cardinality application or workstation names.
Normalize connection-string construction and, where appropriate, reuse stable credential and callback objects. If the service intentionally connects to many databases or identities, count those pools when planning capacity rather than estimating from one connection string.
Check demand and the database’s capacity
Even correctly disposed connections can be exhausted when concurrent demand exceeds available capacity, especially if operations take a long time. Compare peak simultaneous connection demand across all pools and application processes with what the database can sustain. Do not infer that the application has a leak solely from a full pool.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Rank #4
Understand SqlClient pool defaults and fleet-wide capacity
Microsoft Learn documents these defaults for a single Microsoft.Data.SqlClient pool; they are not universal ASP.NET Core or EF Core settings:
| SqlClient setting | Documented default | Scope and effect |
|---|---|---|
Pooling |
true |
Enables pooling for the connection configuration. |
Min Pool Size |
0 |
Minimum retained connections for a pool; a positive value keeps idle connections and needs a capacity justification. |
Max Pool Size |
100 |
Maximum connections in one pool, not a total shared across a fleet. |
Connect Timeout |
15 seconds |
Bounds the wait to open or obtain a connection; it does not create capacity when a pool is busy. |
SqlClient pools are process-local. They are not shared among containers, hosts, or API replicas. The aggregate potential demand can multiply across distinct pool keys, processes, and instances. Before raising the per-pool maximum, estimate that fleet-wide aggregate and verify the database’s connection and resource budget. A positive minimum pool size also retains idle connections, so justify it with measurements rather than setting it automatically.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose a fix based on evidence
| Evidence | First response | What a larger pool could do |
|---|---|---|
| Reclaimed connections or paths missing close/dispose | Fix deterministic cleanup for connections, readers, commands, and transactions. | May delay the next timeout while leaving the lifecycle fault in place. |
| Long commands, active readers, waits, or blocking | Investigate query duration and database contention; shorten the time each connection is occupied. | May permit more concurrent work but can increase pressure on an already saturated database. |
| Long or unfinished transactions | Bound transaction scope and complete or roll back reliably. | Does not release connections held by unfinished work. |
| Many pools for one apparent workload | Normalize connection configuration and account for intentional identity or database differences. | Raises the limit per pool and can amplify aggregate demand across fragmented pools. |
| Healthy short operations but peak concurrent demand exceeds the verified budget | Limit or shape concurrency, or plan a database capacity change based on measured demand. | May be appropriate only if the database can sustain the additional simultaneous connections. |
Use the evidence to decide whether to fix lifecycle, shorten work, normalize pool keys, control concurrency, change a pool limit, or increase database capacity. A database capacity change is not a substitute for fixing a client-side leak, long transaction, or fragmented pool.
Avoid fixes that hide the cause or trigger another incident
Do not routinely clear pools
ClearPool and ClearAllPools empty or reset pools. Connections currently in use are discarded when returned, and subsequent opens need physical logins. Current SqlClient guidance reserves clearing for a real credential, token, or configuration boundary, or for diagnosed stale connections. It is not routine maintenance or a substitute for disposal, and it can cause a burst of physical logins.
Do not treat retries or longer timeouts as added capacity
Retries and longer waits do not create connections. Bound connection attempts and retries, particularly during failover or scale-out, and make sure the database and query/transaction behavior can support the target concurrency. SqlClient’s authentication blocking period is a separate behavior for authentication failures: its documented first period is 5 seconds, doubling after repeated failures up to 1 minute. That is not the pool-checkout timeout. Disabling authentication blocking can turn a credential or network outage into repeated authentication attempts.
Validate the change under the workload that caused the incident
After making a targeted change, compare the same signals across a representative peak: pool and pool-group counts, active and available connections, hard and soft connects, reclaimed connections, connection wait failures, command duration, transaction duration, database sessions and waits, and request latency. If you changed a maximum, include all processes, replicas, and pool keys in the connection budget. A reduction in checkout timeouts is not sufficient evidence of a safe fix if database waits or resource pressure have worsened.
For provider-specific defaults and diagnostics, use the documentation for the deployed driver and version. The detailed defaults and SqlClient counter guidance here do not establish equivalent behavior for Npgsql or every other database provider.
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.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors
