Error 17809: The Maximum Number of User Connections Has Been Reached

Fix it now

17809’s published text says the maximum number of user connections has been reached and that an administrator can use sp_configure to increase it. That wording settles the argument: this is a configuration ceiling, not a licence check. Either somebody set the ceiling low, or something is leaking connections.

SELECT @@MAX_CONNECTIONS AS Ceiling;
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'user connections';
SELECT COUNT(*) AS Sessions, program_name, host_name, login_name
FROM sys.dm_exec_sessions WHERE is_user_process = 1
GROUP BY program_name, host_name, login_name ORDER BY Sessions DESC;

1. Read @@MAX_CONNECTIONS. The documented default for the option is 0, which means the maximum of 32,767 is allowed, so a small number here is something a person set.
2. Read the session grouping. Hundreds of sessions from one program name and host is a pooling problem, not a capacity problem, and raising the ceiling only postpones it.
3. If the ceiling is genuinely too low, set it back: EXEC sp_configure 'user connections', 0; RECONFIGURE; then restart the instance, because the option only takes effect on restart.
4. Separately, count the users and devices that now reach this instance and check that against what you are licensed for. Nothing in the engine does that for you.

17810 is a different error and looks tempting when you are scanning a log. Its published text is about dedicated administrator connections, not user connections, so it is not evidence of anything here.

If new connections succeed and the session count is stable, you are done. If it climbs again by tomorrow, the next section explains where it is going.

Why it happens

The user connections option puts an upper bound on concurrent user connections. Microsoft documents its default as 0, which means the maximum of 32,767 user connections is allowed, and the engine is limited by memory and worker threads long before that. So a non-zero value is always something a person set, often years ago as a crude guard against a runaway application. When the ceiling is reached, new connections are refused while existing ones carry on, which is why new users cannot log in while everyone already working is fine.

Two documented details save a lot of time here. First, user connections is an advanced option, so sp_configure will not even acknowledge the name until show advanced options is 1 – otherwise you get error 15123 and conclude the option does not exist. Second, the change requires a service restart. The informational message 15457 confirms the new value is recorded and tells you to run RECONFIGURE, and comparing value with value_in_use in sys.configurations tells you whether the restart has actually happened.

The more common cause is not the ceiling but a pooling leak. Client libraries keep a pool per unique connection string, and code that opens connections without disposing of them exhausts that pool and keeps opening more. Two signs give it away: the session count climbs steadily through the day rather than tracking user activity, and most sessions are sleeping with no request in flight.

One error is worth taking off the table before you start. 17810 sits next to 17809 numerically and reads similarly at a glance, but its published text is that the maximum number of dedicated administrator connections already exists, and that the existing one must be dropped first. Microsoft’s own page on the diagnostic connection confirms it: only one DAC is allowed per instance, and a second request is denied with 17810. It says nothing about user connection capacity, and reading it as though it did sends you looking for a ceiling that is not there.

Full reference

The option, precisely as documented

USE master;
GO
EXECUTE sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
EXECUTE sp_configure 'user connections', 0;
GO
RECONFIGURE;
GO
EXECUTE sp_configure 'show advanced options', 0;
GO
RECONFIGURE;
GO

Telling capacity from leakage

Queries worth keeping

Why raising the number is rarely the answer

The engine already bounds itself by memory and by the worker pool, both of which reflect what the machine can actually do. A fixed number set by hand reflects what somebody once guessed, and raising it converts a clean refusal into a slower, less obvious failure once workers or memory run short instead. If the sessions are real, capacity is the question. If they are sleeping and multiplying, the number is not the problem and changing it buys a few days at most.

The one thing not to do

Do not use KILL to clear a connection count. Rolling back an open transaction can take longer than the work it undoes, you will not know what you interrupted, and the session that was leaking will simply open another. Find the application, restart it, and fix the disposal.

What the engine does and does not enforce

• It enforces the user connections ceiling, and reports 17809 when it is reached.
• It enforces nothing about client access licences. There is no counter, no warning and no refusal on that basis anywhere in the product.
• That is why entitlement and reality drift apart quietly over years, and why an error like this is often the first time anyone counts.
• The count that matters commercially is of the people and devices that use the system, which is not the same as the number of connections a middle tier holds open.

Every code this article covers

Confirm the fix worked

1. SELECT @@MAX_CONNECTIONS; returns the value you intended, after the restart.
2. value and value_in_use for user connections in sys.configurations now match.
3. The session count sits at a stable level that tracks activity rather than climbing all day.
4. The application that was refused connects, and its own logs show no further connection failures.
5. You have a current count of the users or devices reaching this instance, and licensing that matches it.

Questions people ask about this