SQL Server Error 17809

Error number

17809

Severity

20 (fatal: the connection ends; may indicate a serious problem)

State

Not documented by Microsoft (not reproduced here)

Product

Microsoft SQL Server Database Engine

Versions

All supported SQL Server versions (2016 to 2025); Azure SQL Database limits sessions per service tier and reports it differently

Category

Logins & Permissions

Last reviewed

24 October 2026

What it means

Error 17809 means SQL Server refused a new connection because the instance already holds as many user connections as it allows, so the login never started.

Every connection to the instance uses a user connection slot. The user connections option sets how many may exist at once; its default, 0, means the maximum of 32,767. When the limit is reached, the next connection attempt is closed before login completes and SQL Server writes 17809 to the error log. The number in quotes is the limit that was in force, which is the quickest clue: a small number such as 200 means someone set user connections deliberately, while a number near 32,767 means something really did open that many connections.

Severity 20 here describes the failed connection, not damage to a database: existing sessions keep working and nothing is corrupted. In practice the cause is almost always on the client side (an application that opens connections and never closes them, or a pool configured far larger than needed), so the diagnostics look at who holds the connections before anything is changed on the server.

Common causes

• A connection leak: application code opens connections and does not close or dispose of them, so the pool keeps growing or sessions pile up while they sleep.
• Many application servers or processes, each with its own connection pool (SqlClient defaults to a Max Pool Size of 100 per connection string), together exceeding the limit.
• The user connections option set to a low, non-zero value years ago and forgotten.
• Connection strings that differ slightly per request (user name, application name, database), which creates a separate pool for each variant instead of sharing one.
• A burst of new connections after a failover, restart or deployment, often amplified by aggressive client retry logic.

Diagnose it

Read-only These queries only read metadata and dynamic management views. They do not change data, permissions or configuration, so they are safe to run first.

SELECT name, value, value_in_use
FROM sys.configurations
WHERE name = N'user connections';

SELECT @@MAX_CONNECTIONS AS max_connections;

SELECT TOP (20) s.host_name, s.program_name, s.login_name,
       COUNT(*) AS sessions,
       SUM(CASE WHEN s.status = N'sleeping' THEN 1 ELSE 0 END) AS sleeping,
       MIN(s.last_request_end_time) AS oldest_last_request
FROM sys.dm_exec_sessions AS s
WHERE s.is_user_process = 1
GROUP BY s.host_name, s.program_name, s.login_name
ORDER BY sessions DESC;

SELECT c.client_net_address, c.net_transport, COUNT(*) AS connections
FROM sys.dm_exec_connections AS c
GROUP BY c.client_net_address, c.net_transport
ORDER BY connections DESC;

SELECT s.session_id, s.host_name, s.program_name, s.login_name,
       s.last_request_end_time, s.open_transaction_count
FROM sys.dm_exec_sessions AS s
WHERE s.is_user_process = 1
  AND s.status = N'sleeping'
  AND s.last_request_end_time < DATEADD(MINUTE, -30, SYSDATETIME())
ORDER BY s.last_request_end_time;

SELECT name, state_desc
FROM sys.endpoints
WHERE name = N'Dedicated Admin Connection';

SELECT name, value_in_use
FROM sys.configurations
WHERE name = N'remote admin connections';

How to fix it

Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.

// C#: the connection goes back to the pool even if the query throws
using (var cn = new SqlConnection(connectionString))
using (var cmd = new SqlCommand("SELECT COUNT(*) FROM dbo.Orders", cn))
{
    cn.Open();
    var count = (int)cmd.ExecuteScalar();
}

-- Over the DAC, after confirming the session belongs to the leaking application
KILL 87;

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'user connections', 0;   -- 0 = default (32,767)
RECONFIGURE;
-- takes effect after the next service restart

Examples

A new connection is refused when the limit is reached

Shown as documented by Microsoft; not reproduced here, because it needs the instance-wide connection limit to be reached. The message text is from sys.messages on SQL Server 2025 with an example limit of 200; the state written to the error log was not observed, so no header is shown.

-- Any new connection, for example
sqlcmd -S ServerName -E -Q "SELECT 1"

Could not connect because the maximum number of '200' user connections has already been reached. The system administrator can use sp_configure to increase the maximum value. The connection has been closed.

How to prevent it

Treat connections as short-lived resources in application code, keep pools sized from measurements, and monitor the number of user sessions per application over time so that slow growth from a leak shows up long before the limit.

Leave user connections at its default unless you have a measured reason, document any cap you set, and test once that administrators can reach the instance through the dedicated admin connection before they need it.

Common questions

Learn more on CodeWithSQL

• Performance tuning

Official documentation

• MSSQLSERVER_17809 (Microsoft Learn)
• Server configuration: user connections
• Diagnostic connection for database administrators
• SQL Server connection pooling (ADO.NET)

Last technically reviewed 24 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.