🚨 Azure Error Guide: 'Error 40613: Database is not currently available' — Restore SQL Connectivity

Overview

Azure SQL Database returns error 40613 when the target database is temporarily unreachable — during a failover, reconfiguration, scaling operation, or while a serverless database is resuming. Clients see:

Msg 40613, Level 16, State 1, Line 1
Database 'salesdb' on server 'myserver.database.windows.net' is not currently available.
Please retry the connection later. If the problem persists, contact customer support,
and provide them the session tracing ID of '{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}'.

It is usually transient: the platform is moving or reconfiguring your database’s replica, and the connection should succeed on retry within seconds to a minute.

Symptoms

• Intermittent connection failures with 40613 that clear on their own after a short retry.
• Apps throw SqlException number 40613 during Azure-side maintenance windows or right after a scale (DTU/vCore) change.
• A serverless database returns 40613 on the first connection after being idle (auto-paused), then works once resumed.
• Bursts of 40613 correlate with a geo-failover or planned maintenance event.
• Persistent (not transient) 40613 that never clears — pointing at a paused/offline database or a hitting-limits condition.

Common Root Causes

• Planned or unplanned failover/reconfiguration. Azure SQL periodically moves databases between replicas for patching, load balancing, or hardware issues; connections drop briefly.
• Scaling operation in progress. Changing service tier, DTUs, or vCores makes the database briefly unavailable while it reconfigures.
• Serverless auto-pause. A serverless database that auto-paused after inactivity returns 40613 on the first connection while it resumes.
• Hitting resource limits. Sustained max DTU/vCore or worker/session exhaustion can make the database reject new connections.
• Missing retry logic. The app treats a transient, expected failover as a hard failure because it has no retry-with-backoff.
• Database offline or mid-restore. A database being restored, copied, or in an error state is genuinely unavailable, not transiently.

Diagnostic Workflow

All commands below are read-only. Confirm the database’s state and tier:

# Is the database Online, Paused, or in another state? What tier/capacity?
az sql db show --resource-group <rg> --server <server> --name <db> \
  --query "{status:status, tier:sku.tier, capacity:sku.capacity, autoPause:autoPauseDelay}" --output json

Check resource utilization to rule out a limits-driven (non-transient) cause:

# DTU/CPU/worker consumption over the last hour.
az monitor metrics list --resource $(az sql db show -g <rg> -s <server> -n <db> --query id -o tsv) \
  --metric "dtu_consumption_percent" "cpu_percent" "workers_percent" \
  --interval PT1M --output table

Review platform-side events (failovers/maintenance) and connectivity:

# Recent operations on the database (scaling, failover, restore).
az monitor activity-log list --resource-group <rg> --offset 6h \
  --query "[?contains(resourceId, '<db>')].{op:operationName.value, status:status.value, time:eventTimestamp}" --output table

# Confirm the server is reachable and firewall allows you.
az sql server firewall-rule list -g <rg> -s <server> --output table

Example Root Cause Analysis

A cost-optimized reporting database on the serverless tier returned 40613 every morning on the first query, then worked fine for the rest of the day. The pattern — always the first connection after overnight idle — was the tell.

az sql db show reported status: Paused before the morning query and an autoPauseDelay of 60 minutes, confirming the serverless database auto-paused overnight. The first connection triggered a resume, which takes a short time and surfaced 40613 while the database came online. Metrics showed no DTU/worker pressure, ruling out a limits problem.

The fix had two parts: add transient-fault retry logic (exponential backoff) so the resuming connection retries instead of failing, and — because the morning delay mattered — either raise the auto-pause delay or run a lightweight keep-warm query before business hours. After adding retries the morning failures disappeared. Root cause: serverless auto-pause resume surfacing as a transient 40613, correctly handled by retry.

Prevention Best Practices

• Implement retry logic with exponential backoff. Treat 40613 (and related transient error numbers like 40501, 49918, 4060) as retryable; SDK resilience or Polly-style policies handle this cleanly.
• Tune serverless auto-pause. Raise autoPauseDelay or add a keep-warm ping if first-connection latency after idle is unacceptable.
• Right-size the tier. If 40613 correlates with sustained max DTU/vCore or worker exhaustion, scale up or optimize workload — that is not a transient failover.
• Schedule around maintenance. Use maintenance windows so reconfigurations happen at predictable low-traffic times.
• Use connection pooling wisely. Ensure the pool validates connections and retries on transient faults rather than handing out dead connections.
• Monitor and alert on DTU/worker percent and database status so a persistent (non-transient) 40613 is caught quickly.

Quick Command Reference

# Check database status, tier, and auto-pause.
az sql db show -g <rg> -s <server> -n <db> --query "{status:status, tier:sku.tier, autoPause:autoPauseDelay}"

# Review DTU/CPU/worker utilization.
az monitor metrics list --resource <dbId> --metric dtu_consumption_percent workers_percent --interval PT1M

# Look for recent scaling/failover operations.
az monitor activity-log list -g <rg> --offset 6h -o table

# Confirm firewall/connectivity.
az sql server firewall-rule list -g <rg> -s <server> -o table

# Update auto-pause delay for a serverless DB (minutes; -1 to disable).
az sql db update -g <rg> -s <server> -n <db> --auto-pause-delay 120

Conclusion

Error 40613 almost always means Azure SQL is briefly reconfiguring, failing over, or resuming your database — a transient condition that a retry with backoff resolves. Confirm the database status and utilization: a Paused serverless database needs retry plus auto-pause tuning, while a database pinned at its DTU/worker limits needs right-sizing rather than retries. Building transient-fault handling into every Azure SQL client is the single most effective fix for this class of error.