Introduction

In Entity Framework, "database timeout" can mean two different things: how long the client waits to establish a connection, and how long it waits for a SQL command to finish. Those settings live in different places, and confusing them is a common reason timeout fixes appear to do nothing.

Connection Timeout vs Command Timeout

The connection timeout is part of the connection string. It affects how long the provider waits while opening the database connection.

The command timeout affects how long EF allows an individual query or command to run after the connection is already open.

If a query times out after thirty seconds, changing the connection string may not help. You probably need to change the command timeout instead.

Entity Framework 6: Set Database.CommandTimeout

In EF6, the usual way to change command timeout is through the context:

1using (var context = new AppDbContext())
2{
3    context.Database.CommandTimeout = 180;
4
5    var customers = context.Customers
6        .Where(c => c.IsActive)
7        .ToList();
8}

The value is in seconds. This affects commands executed through that context instance.

If you need a global default for a specific context type, set it in the constructor:

1public class AppDbContext : DbContext
2{
3    public AppDbContext() : base("name=AppDb")
4    {
5        this.Database.CommandTimeout = 180;
6    }
7}

That is often the cleanest approach when the same timeout rule should apply to the whole application.

Entity Framework Core: Use SetCommandTimeout

In EF Core, the usual pattern is:

1using var context = new AppDbContext();
2context.Database.SetCommandTimeout(180);
3
4var orders = context.Orders
5    .Where(o => o.Status == "Open")
6    .ToList();

You can also configure the timeout when registering the provider:

1services.AddDbContext<AppDbContext>(options =>
2    options.UseSqlServer(
3        connectionString,
4        sqlOptions => sqlOptions.CommandTimeout(180)));

This is useful when you want the timeout policy centralized in application startup rather than repeated in query code.

Connection Timeout Lives in the Connection String

If the issue is opening the connection itself, change the connection string instead:

Server=.;Database=AppDb;Trusted_Connection=True;Connect Timeout=30;

This setting is separate from command timeout. It helps when the network or SQL Server instance is slow to accept the connection, but it will not make a long-running query continue longer once execution has begun.

Do Not Use Large Timeouts to Hide Slow Queries

Raising a timeout can be the right tactical fix for a known long-running operation such as a migration, report, or bulk import. It should not be the default response to every timeout exception.

If normal application queries keep timing out, the real issue may be:

• missing indexes
• blocking or deadlocks
• inefficient LINQ translation
• fetching too much data

In those cases, a bigger timeout only delays the error and makes the user wait longer.

Common Pitfalls

The biggest mistake is changing the connection string when the failure is really a command timeout. Those are different settings and solve different problems.

Another common issue is setting the timeout on one context instance and expecting it to affect all future contexts automatically. In EF, that only happens if you centralize the configuration yourself.

It is also easy to treat timeouts as a database-performance strategy. A timeout value is a safety boundary, not a substitute for query tuning and indexing.

Summary

• Entity Framework timeout configuration depends on whether the problem is connection opening or command execution.
• In EF6, use Database.CommandTimeout for per-context command timeout control.
• In EF Core, use Database.SetCommandTimeout or provider configuration during startup.
• Use Connect Timeout in the connection string only for connection-establishment delays.
• Increase timeouts deliberately, but fix slow queries instead of masking them permanently.