Introduction

SqlConnection.ConnectionTimeout and SqlCommand.CommandTimeout sound similar because both are measured in seconds and both can produce timeout errors. But they guard different phases of database work.

ConnectionTimeout controls how long the client waits while opening the connection. CommandTimeout controls how long a SQL command is allowed to execute after the connection is already open.

ConnectionTimeout Applies While Connecting

SqlConnection.ConnectionTimeout is about the Open() phase. It covers the time spent trying to establish a session with SQL Server:

1using System;
2using System.Data.SqlClient;
3
4var connectionString =
5    "Server=localhost;Database=AppDb;Trusted_Connection=True;Connection Timeout=5;";
6
7using var connection = new SqlConnection(connectionString);
8
9try
10{
11    connection.Open();
12    Console.WriteLine("Connected");
13}
14catch (SqlException ex)
15{
16    Console.WriteLine(ex.Message);
17}

If the server is unreachable, the network is slow, or authentication cannot complete in time, the connection attempt times out.

This setting does not control query execution time. Once the connection is open, its job is done.

CommandTimeout Applies While Executing SQL

SqlCommand.CommandTimeout starts to matter only after you already have a connection and are executing a statement:

1using System;
2using System.Data.SqlClient;
3
4var connectionString =
5    "Server=localhost;Database=AppDb;Trusted_Connection=True;Connection Timeout=5;";
6
7using var connection = new SqlConnection(connectionString);
8connection.Open();
9
10using var command = new SqlCommand("WAITFOR DELAY '00:00:10';", connection);
11command.CommandTimeout = 2;
12
13try
14{
15    command.ExecuteNonQuery();
16}
17catch (SqlException ex)
18{
19    Console.WriteLine(ex.Message);
20}

In this example, the connection opens successfully, but the command times out because the SQL work takes too long.

That is the core difference:

• 'ConnectionTimeout is about getting connected'
• 'CommandTimeout is about finishing the SQL command'

Why Confusing Them Causes Bad Fixes

Suppose a query is slow because of missing indexes or bad execution plans. Increasing ConnectionTimeout will not help, because the connection is not the slow part.

Likewise, if the SQL Server host is unavailable, changing CommandTimeout will not help because the command never even begins execution.

This is why timeout tuning should start with identifying the failing phase instead of just increasing both numbers.

Where Each Value Comes From

ConnectionTimeout usually comes from the connection string:

Connection Timeout=15;

CommandTimeout is commonly set per command object:

command.CommandTimeout = 60;

This difference is practical. You might want one consistent connection timeout for the whole application, while individual queries may need different execution limits depending on workload.

For example:

• a quick lookup might deserve 5 seconds
• a reporting query might deserve 120 seconds

Those are command-level decisions, not connection-level ones.

Defaults and Expectations

In many ADO.NET scenarios:

• connection timeout defaults to 15 seconds
• command timeout defaults to 30 seconds

Even when the defaults are acceptable, understanding them is still important for debugging. A timeout exception without context often leads to the wrong fix if you do not know which layer timed out.

Common Pitfalls

• Increasing ConnectionTimeout when the real issue is a slow query.
• Increasing CommandTimeout when the real issue is network or server reachability.
• Assuming both settings apply to the entire lifetime of the database interaction.
• Forgetting that CommandTimeout is per command, not a property of the connection.
• Using a huge timeout to hide an underlying performance problem instead of diagnosing the root cause.

Summary

• 'ConnectionTimeout controls how long SqlConnection.Open() may take.'
• 'CommandTimeout controls how long a SQL command may execute after the connection is open.'
• They apply to different phases and solve different problems.
• Tune the one that matches the actual failing step.
• Do not treat large timeout values as a substitute for fixing query or infrastructure issues.