Fix: Error 40613: Database is not currently available (Azure SQL)

Error 40613 tells you that Azure SQL Database cannot accept your connection right now. The full message names the database and server and asks you to retry later. It is one of the most common errors you will see against Azure SQL, and in most cases it is not a sign that anything is broken. It is the platform telling you to wait a moment and try again.

What this error means

Azure SQL Database is a managed service. The platform moves your database between physical replicas, patches the underlying hosts, and reconfigures resources without asking you first. During those brief windows your existing connections drop and new ones are refused, and you get 40613. The correct default response is to retry with backoff, because the database is usually back within seconds.

The same error code can also mean something less transient: the database is paused, mid scale, or under enough resource pressure that it cannot take new work. So 40613 is best read as “not available yet,” and your job is to decide whether that is a two second blip or a real problem.

Common causes

• A service-managed failover or reconfiguration moved the database to another replica.
• A serverless database is resuming from auto-pause on its first connection after idle time.
• A scale operation (changing tier, DTU, or vCore) is in progress and briefly interrupts availability.
• Sustained DTU, CPU, or IO saturation is preventing the database from accepting new connections.
• A regional Azure incident is affecting the SQL service, visible in Azure Service Health.
• Connection pool exhaustion or aggressive reconnect storms are compounding a short outage.

How to fix it

Stabilize

1. Retry with exponential backoff before doing anything else. 40613 is on the documented list of retryable Azure SQL error codes, alongside 40197, 40501, 49918, 10928, and 10929. A short retry loop resolves the large majority of occurrences.

var delay = TimeSpan.FromSeconds(1);
for (int attempt = 1; attempt <= 6; attempt++)
{
    try
    {
        await using var conn = new SqlConnection(connectionString);
        await conn.OpenAsync();
        break;
    }
    catch (SqlException ex) when (ex.Number is 40613 or 40197 or 40501 or 49918 or 10928 or 10929)
    {
        if (attempt == 6) throw;
        await Task.Delay(delay);
        delay = TimeSpan.FromSeconds(Math.Min(30, delay.TotalSeconds * 2));
    }
}

2. If the database is serverless and has been idle, understand that the first connection is waking it up. Allow a longer retry budget (around sixty seconds) for that first hit.

Diagnose

1. Check Azure Service Health and open the database resource in the portal to rule out a regional incident or an in-progress scale operation.

2. Once you can connect, check whether you were resource bound just before the failure.

SELECT TOP (30) end_time,
       avg_cpu_percent,
       avg_data_io_percent,
       avg_log_write_percent,
       max_worker_percent,
       max_session_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC;

3. For a longer view across the last fourteen days, query the master database.

SELECT TOP (100) start_time,
       database_name,
       avg_cpu_percent,
       avg_data_io_percent,
       avg_log_write_percent
FROM sys.resource_stats
WHERE database_name = 'mydb'
ORDER BY start_time DESC;

4. Confirm whether the database is serverless and check its auto-pause setting from the Azure CLI.

az sql db show \
  --resource-group myResourceGroup \
  --server myserver \
  --name mydb \
  --query "{tier:sku.tier, autoPause:autoPauseDelay, minCap:minCapacity}"

Fix

1. Add proper transient-fault retry everywhere you open connections. With Entity Framework Core, enable the built-in resilient execution strategy.

services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString,
        sql => sql.EnableRetryOnFailure(
            maxRetryCount: 6,
            maxRetryDelay: TimeSpan.FromSeconds(30),
            errorNumbersToAdd: null)));

If you are on raw SqlClient, wrap opens in the loop shown above. The older Microsoft.Data.SqlClient and legacy Transient Fault Handling Application Block both cover these same codes if you already depend on them.

2. If diagnosis shows you were resource capped, scale the service tier up.

az sql db update \
  --resource-group myResourceGroup \
  --server myserver \
  --name mydb \
  --service-objective S3

3. If auto-pause is causing painful cold starts, raise the delay or disable it for latency-sensitive workloads.

az sql db update \
  --resource-group myResourceGroup \
  --server myserver \
  --name mydb \
  --auto-pause-delay 120

4. Use connection pooling correctly. Keep pooling enabled (it is on by default), avoid opening a connection per operation, and open connections late and close them early so a short outage does not cascade into pool exhaustion.

How to prevent it

• Put transient-fault retry logic in every path that opens a connection, not just the hot ones.
• Right-size the service tier to your real DTU or vCore usage with headroom for spikes.
• Monitor sys.dm_db_resource_stats and set alerts on CPU, IO, and worker percent.
• Configure Azure Service Health alerts so you learn about platform events before your users do.
• For serverless, tune the auto-pause delay to match your traffic pattern.

When to call a senior engineer

If 40613 persists past a sensible retry budget, recurs on a schedule, or lines up with resource saturation you cannot explain, the cause is no longer a simple blip. Repeated availability failures under load usually point to an undersized tier, a connection-handling bug, or a query pattern that is exhausting resources. Erzon can get on the incident, confirm the real cause, and put durable retry and capacity fixes in place.