Database Connection Errors — Application Unable to Establish or Maintain Database Connectivity Due to Pool Exhaustion, Network, or Server Faults

Indicators

• Application logs report 'Failed to open database connection' or 'Connection timeout expired'
• HTTP 500 or 503 responses returned to end users coinciding with database access attempts
• Connection pool exhaustion messages: 'Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool'
• Database server logs show 'max_connections limit reached' or 'too many connections'
• Authentication failure errors: 'Login failed for user' or 'password authentication failed'
• Network-level errors: 'A network-related or instance-specific error occurred while establishing a connection to SQL Server'

Likely causes

• Connection pool exhausted due to connection leaks (connections opened but not closed/returned to pool) or insufficient pool size for current load
• Incorrect or stale connection string (wrong host, port, credentials, or database name) in application configuration
• Network connectivity failure between application host and database host (firewall rule change, routing issue, or DNS resolution failure)
• Database server unavailable due to crash, OOM condition, service stopped, or maintenance window
• Authentication failure caused by expired password, revoked certificate, locked account, or misconfigured authentication method
• Database server reached maximum allowed connections and is rejecting new connection attempts

Diagnostic steps

1. Review application logs for the exact error message returned when a connection attempt fails, noting the timestamp, error code, and any stack trace. Check Windows Event Viewer > Application log for related errors.
   Identifies whether the failure is a timeout, authentication error, connection refused, or pool exhaustion, which determines the diagnostic path.
2. Test basic network connectivity from the application host to the database host and port: - Windows: `Test-NetConnection -ComputerName <db-host> -Port <db-port>` - Linux: `telnet <db-host> <db-port>` or `nc -zv <db-host> <db-port>`
   Confirms whether a TCP connection can be established, ruling out network-layer or firewall-layer failures.
3. Check current connection count against configured maximum on the database server: - SQL Server: `SELECT COUNT(*) AS connections FROM sys.dm_exec_connections;` and `SELECT @@MAX_CONNECTIONS;` - MySQL: `SHOW STATUS LIKE 'Threads_connected';` and `SHOW VARIABLES LIKE 'max_connections';` - PostgreSQL: `SELECT count(*) FROM pg_stat_activity;` and `SHOW max_connections;`
   Determines whether the database server is at or near its connection limit, which would cause new connection attempts to be rejected.
4. Validate the connection string in the application configuration, confirming host, port, database name, username, and password are correct. Test with a direct database client from the application server: - SQL Server: `sqlcmd -S <server> -U <user> -P <password> -d <database> -Q "SELECT 1"` - MySQL: `mysql -h <host> -u <user> -p<password> -e "SELECT 1"` - PostgreSQL: `psql -h <host> -U <user> -d <database> -c "SELECT 1"`
   Rules out misconfiguration or stale credentials as the root cause of connection failures.
5. Check database server error logs and system resource utilisation: - SQL Server: Check SQL Server Error Log and `SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC;` - Windows: Performance Monitor for CPU, memory, disk I/O - Check for OOM events in Windows Event Log > System
   Identifies whether the database server itself is unhealthy and needs to be restarted or scaled before connections can succeed.
6. Identify connection-consuming queries or blocked sessions: - SQL Server: `SELECT * FROM sys.dm_exec_requests WHERE blocking_session_id <> 0;` - PostgreSQL: `SELECT * FROM pg_stat_activity WHERE state != 'idle' ORDER BY query_start;`
   Identifies long-running or blocked queries that may be holding connections and preventing pool recycling.

Resolution path

• If connection pool is exhausted: increase the pool size in the application connection pool configuration (e.g., `Max Pool Size=200` in .NET connection string), audit application code for connection leaks (connections opened but not properly disposed), and implement `using` statements or try-finally blocks to ensure connections are returned to the pool.
• If connection string is incorrect: update the connection string in the application configuration or secret store with the correct host, port, credentials, and database name, then restart the application service to pick up the new configuration: `Restart-Service <AppServiceName>` or recycle the IIS application pool: `Restart-WebAppPool -Name <PoolName>`
• If the database server has reached max connections on SQL Server: terminate idle connections with `KILL <spid>;` after identifying them via `SELECT session_id, login_name, status, last_request_end_time FROM sys.dm_exec_sessions WHERE status = 'sleeping' AND last_request_end_time < DATEADD(MINUTE, -30, GETDATE());`
• If the database server has reached max connections on MySQL: terminate idle connections with `KILL <connection_id>;` and increase limit: edit my.cnf to set `max_connections = 500` then restart MySQL service.
• If the database server has reached max connections on PostgreSQL: terminate idle connections with `SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE state = 'idle' AND query_start < NOW() - INTERVAL '30 minutes';` and increase max_connections in postgresql.conf (requires restart).
• If a network or firewall issue is confirmed: update the relevant Windows Firewall rule (`New-NetFirewallRule -DisplayName "Allow SQL" -Direction Inbound -LocalPort 1433 -Protocol TCP -Action Allow`) or security group to permit traffic from the application host to the database host on the required port.

Prevention

• Implement connection pool monitoring and alerting so that pool exhaustion is detected before it causes an outage - set alerting thresholds at 75% of maximum pool size
• Store database credentials in a secrets manager (Azure Key Vault, AWS Secrets Manager) with automated rotation, and configure the application to reload credentials without restart to prevent stale-credential connection failures after rotation
• Set connection timeouts and maximum lifetime values in the connection pool configuration (e.g., `Connection Lifetime=300;Connection Timeout=30` in .NET) to automatically evict idle or stale connections
• Implement health checks that verify database connectivity as part of application startup and readiness probes
• Configure database server alerting for connection count approaching maximum (alert at 80% of max_connections)
• Use connection pooling middleware (e.g., PgBouncer for PostgreSQL, ProxySQL for MySQL) to efficiently manage connection reuse across application instances

Tools

• Test-NetConnection / telnet / nc (TCP connectivity test to database port)
• sqlcmd / mysql / psql (direct database connectivity and query execution)
• SQL Server Management Studio (SSMS) (database administration and query analysis)
• Application log aggregator - Splunk, ELK, CloudWatch Logs (error pattern analysis)
• Performance Monitor / perfmon (Windows server resource monitoring)
• sys.dm_exec_connections / pg_stat_activity / SHOW PROCESSLIST (active connection inspection)

References

• SQL Server Connection Pooling (ADO.NET)
• Troubleshoot connecting to the SQL Server Database Engine
• PostgreSQL: Managing Connections
• MySQL: Too Many Connections