Introduction

With ADO.NET and SQL Server, “timeout” can refer to two different operations: opening the connection or executing a command. That distinction matters because SqlConnection timeout is configured in the connection string, while query timeout lives on SqlCommand.

Connection Timeout and Command Timeout Are Different

A lot of confusion comes from assuming one setting controls all database delays. It does not.

Connection timeout:

• applies during connection.Open()
• controls how long ADO.NET waits to establish the SQL Server connection
• is set in the connection string

Command timeout:

• applies after the connection is already open
• controls how long a SQL statement may run
• is set on the SqlCommand

If Open() fails, changing CommandTimeout does nothing. If the query times out after the connection succeeds, changing Connect Timeout does nothing.

Change the Connection Timeout in the Connection String

The SqlConnection.ConnectionTimeout property is read-only. You do not assign to it directly. Instead, you define the timeout before opening the connection.

Using SqlConnectionStringBuilder is the safest option:

1using System;
2using System.Data.SqlClient;
3
4var builder = new SqlConnectionStringBuilder
5{
6    DataSource = "localhost",
7    InitialCatalog = "SalesDb",
8    IntegratedSecurity = true,
9    ConnectTimeout = 30
10};
11
12using var connection = new SqlConnection(builder.ConnectionString);
13connection.Open();
14
15Console.WriteLine($"Connection timeout: {connection.ConnectionTimeout}");

You can also set it directly in the raw connection string:

1using var connection = new SqlConnection(
2    "Server=localhost;Database=SalesDb;Integrated Security=true;Connect Timeout=30;");
3
4connection.Open();

Both forms do the same thing. The builder is simply less error-prone when the string has many settings.

Change Query Timeout on the Command

If the connection opens successfully but the SQL itself runs too long, set CommandTimeout instead.

1using System;
2using System.Data.SqlClient;
3
4using var connection = new SqlConnection(
5    "Server=localhost;Database=SalesDb;Integrated Security=true;Connect Timeout=15;");
6
7connection.Open();
8
9using var command = new SqlCommand(
10    "WAITFOR DELAY '00:00:05'; SELECT 1;",
11    connection);
12
13command.CommandTimeout = 2;
14
15try
16{
17    command.ExecuteScalar();
18}
19catch (SqlException ex) when (ex.Number == -2)
20{
21    Console.WriteLine("Command timed out.");
22}

This example shows a command timeout, not a connection timeout. The connection was already established before the long-running SQL began.

A Practical Way to Diagnose the Problem

When a team says “SQL timed out,” first determine where it happened:

1. Did connection.Open() fail
2. Did the connection open but ExecuteReader(), ExecuteScalar(), or ExecuteNonQuery() fail
3. Is the application actually waiting on a connection from the pool rather than on SQL Server itself

These cases can look similar in logs if the code only records a generic timeout message.

The fix depends on the answer:

• slow or unreachable server: inspect connection and network path
• slow query: inspect indexes, plans, and blocking
• pool exhaustion: inspect connection disposal and pool usage

Avoid Using Larger Timeouts as a Bandage

Increasing a timeout can be reasonable when:

• the app talks to SQL Server across a slow network
• a legitimate reporting query is expected to run longer
• the timeout was simply too aggressive for the workload

It is a poor fix when normal application queries suddenly start timing out because of:

• missing indexes
• lock contention
• parameter sniffing issues
• overloaded database hardware
• application code holding transactions too long

Timeout changes should reflect expected behavior, not hide a performance regression.

ORMs and Libraries May Add Another Layer

If the project uses Entity Framework, Dapper helpers, or a custom repository layer, there may be multiple timeout settings in play. In those cases, check:

• the raw connection string
• ORM command timeout configuration
• retry policies that may wrap the original exception

Otherwise, you can end up tuning the wrong layer and wondering why the observed behavior does not change.

Common Pitfalls

• Trying to assign directly to connection.ConnectionTimeout even though it is read-only.
• Changing Connect Timeout when the real failure happens during command execution.
• Changing CommandTimeout when the application cannot even establish the initial connection.
• Setting extremely large timeout values instead of investigating the cause of slow queries.
• Ignoring connection-pool exhaustion, which can look like a database timeout but has a different root cause.

Summary

• 'SqlConnection timeout is configured in the connection string, not by setting the property after construction.'
• 'Connect Timeout controls connection establishment, while CommandTimeout controls SQL execution time.'
• Diagnose where the timeout occurs before changing any settings.
• Use larger timeouts only when the workload genuinely justifies them.
• Do not treat timeout tuning as a substitute for fixing slow queries or connection-management problems.