Azure SQL: Fix Common Errors & Setup Problems
Why This Is Happening
You've spun up an Azure SQL database , maybe it's your first time migrating a SQL Server workload to the cloud, or maybe you're three sprints into a new cloud-native app , and something isn't working. The connection string throws an error, the firewall silently drops packets, or the Azure portal shows a red banner you've never seen before. I've seen this exact situation hundreds of times, and I want you to know upfront: it's almost never the database engine itself. The engine is rock-solid. The problems live in the configuration layer around it.
Azure SQL is a family of managed products, Azure SQL Database, Azure SQL Managed Instance, and SQL Server on Azure VMs. Each behaves slightly differently, and that's exactly where most people get tripped up. You search for a fix, find an answer that solves Azure SQL Database firewall issues, apply it, and your problem doesn't move, because you're actually running Azure SQL Managed Instance, which uses network security groups instead of server-level firewall rules. The error messages Azure throws don't usually tell you which product tier is involved. They're maddeningly generic.
The most common pain points I hear about with Azure SQL troubleshooting fall into four buckets. First, connectivity failures, your app can't reach the server at all, and you get timeout errors or "Cannot open server" messages. Second, authentication errors, SQL logins versus Azure Active Directory authentication behave completely differently, and mixing them up breaks everything. Third, performance degradation, queries that ran in milliseconds on-premises now crawl in Azure, usually because the service tier is undersized or auto-tuning hasn't had time to learn the workload. Fourth, migration headaches, features that existed in your on-premises SQL Server simply don't exist in Azure SQL Database, and the migration silently fails or the app crashes at runtime.
The reason Microsoft's error messages don't help much here is structural. Azure SQL is a shared, multi-tenant platform at its core. To protect other tenants, Azure strips out a lot of the low-level diagnostic detail you'd normally see in SQL Server error logs. You don't get OS-level stack traces. You don't get network topology details. You get a friendly, abstracted error that tells you something went wrong without telling you where in the stack.
This guide covers all three products in the Azure SQL family, Azure SQL Database (including Hyperscale and serverless compute tiers), Azure SQL Managed Instance, and SQL Server on Azure VMs. Whether you're dealing with a dropped connection, a failed Azure SQL Database migration from SQL Server, elastic pool misconfiguration, or an Azure SQL advanced threat detection alert you don't understand, I'll walk you through every layer of the fix.
The Quick Fix, Try This First
Before diving into the deep troubleshooting steps, let's knock out the fix that resolves roughly 60% of Azure SQL connection problems in under five minutes. The culprit in most cases is a missing or misconfigured firewall rule at the server level.
Here's what you do. Open the Azure portal at portal.azure.com. Navigate to your SQL server resource, note that this is the logical SQL server, not the individual database. In the left menu, click Networking (it may show as Firewalls and virtual networks on older portal layouts). You'll see a section called Firewall rules.
If you're connecting from your own machine for the first time, click Add your client IPv4 address, Azure will auto-detect your current public IP and add it. If you're connecting from an Azure service like an App Service or an Azure Function, toggle Allow Azure services and resources to access this server to Yes. Click Save at the top. Give it 30 seconds for the rule to propagate, then retry your connection.
If you're using Azure SQL Managed Instance, the above won't apply, Managed Instance doesn't use server-level firewall rules. Instead, it's deployed inside a virtual network (VNet) and access is controlled by Network Security Group (NSG) rules. In that case, jump directly to Step 3 in the step-by-step section below.
For authentication-related errors (error codes 18456 or 40532), the quick check is to confirm you're using the right login type. In the Azure portal, go to your SQL server → Azure Active Directory. If you see an AAD admin set, and you're trying to connect with a SQL login, that can cause conflicts depending on how the server is configured. Try switching your connection string to use the AAD admin credentials first to confirm the server is reachable at all.
For Azure SQL Database performance issues specifically, the fastest diagnostic is the Query Performance Insight blade. Go to your database resource → Intelligent Performance → Query Performance Insight. This shows you the top resource-consuming queries in the last hour. If one query is eating 80% of your DTUs or vCores, you've found your bottleneck without touching a single log file.
This is the step most guides skip, and it's the one that will save you the most time. Azure SQL is not one product, it's three products that look similar in the portal but behave very differently under the hood. Applying the wrong fix to the wrong product is the number one cause of wasted troubleshooting time I see in enterprise environments.
Go to the Azure portal and search for your resource by name. Look at the resource type badge shown under the resource name on the overview page. You'll see one of three labels:
- SQL database, This is Azure SQL Database. It runs on shared infrastructure managed entirely by Microsoft. You get no OS access, no SQL Agent by default, and firewall rules live at the logical server level.
- SQL managed instance, This is Azure SQL Managed Instance. It gives you near-complete SQL Server feature parity, runs inside your VNet, and is managed at the network layer via NSGs. Best for migrations from complex on-premises SQL Server environments.
- SQL virtual machine, This is SQL Server on an Azure VM. You have full OS-level access, 100% SQL Server compatibility, but you manage patching, backups, and HA yourself unless you've configured automated features.
Once you've confirmed which product you're on, navigate to the Properties blade and note down your Server name (ends in .database.windows.net for Azure SQL Database, or .database.windows.net with a different subdomain for Managed Instance public endpoints). You'll need this exact string for your connection tests.
If everything went right, you should now have a clear understanding of what you're working with before you touch a single setting. Skipping this step is how people spend four hours applying firewall rules to an Managed Instance that simply doesn't use them.
Before changing anything, prove to yourself exactly where the connection is failing. A lot of people jump straight to configuration changes, make three things different at once, and then don't know which change fixed it. Let's be methodical.
Open a terminal (PowerShell or Command Prompt on Windows) and run a raw TCP test to port 1433:
Test-NetConnection -ComputerName yourserver.database.windows.net -Port 1433If TcpTestSucceeded comes back False, the problem is network-level, firewall rules, NSG rules, or DNS. If it comes back True, the TCP layer is fine and the problem is authentication or the database name in your connection string.
For Azure SQL Managed Instance with a public endpoint enabled, the port is 3342, not 1433. Test it like this:
Test-NetConnection -ComputerName yourinstance.public.instancename.database.windows.net -Port 3342If you want a deeper test, use sqlcmd directly:
sqlcmd -S yourserver.database.windows.net -U yourusername -P yourpassword -Q "SELECT @@VERSION"A successful response prints the SQL Server version string, something like Microsoft SQL Azure (RTM) - 12.0.2000.8. If you see error 40532 ("Cannot open server requested by the login"), your login is correct but firewall rules are blocking you. Error 18456 means the login itself is wrong or doesn't exist on that server.
Document what you find here. This baseline tells you exactly which section to focus on in the next steps.
Now that you know TCP is failing, let's fix the network layer. The approach differs based on which product you identified in Step 1.
For Azure SQL Database: In the Azure portal, go to your logical SQL server → Networking. Under Firewall rules, verify there's a rule covering your client's IP range. If your app runs on Azure App Service, Function App, or AKS, enable Allow Azure services and resources to access this server. For production environments, don't rely on this toggle, instead, configure a Private endpoint or VNet service endpoint so your app communicates over Azure's private backbone, never over the public internet.
For Azure SQL Managed Instance: Go to your Managed Instance resource → Virtual network / subnet → click the linked NSG. In the NSG's Inbound security rules, ensure there's a rule allowing TCP on port 1433 from your source IP range, with priority lower than any Deny rules. Microsoft automatically creates some default rules when you deploy Managed Instance, don't delete the rules with AllowManagementInbound in the name. Those are required for the managed service to function.
To enable the public endpoint on Managed Instance (for external connections), go to the Managed Instance resource → Networking → set Public endpoint to Enable. Then add an NSG inbound rule for port 3342.
After saving, wait about 60 seconds and re-run the Test-NetConnection command from Step 2. When TcpTestSucceeded returns True, move on.
TCP connectivity is working, but you're still getting login failures. This is the second most common Azure SQL error category, and it comes in a few distinct flavors.
Error 18456, Login failed for user: This usually means either the username is wrong, the password is wrong, or the login doesn't exist on the logical server. In the Azure portal, go to your SQL server → Azure Active Directory and check whether an AAD admin is set. If yes, try connecting with that AAD account first via SSMS using Azure Active Directory, Universal with MFA authentication. If that works, the server is functional and your SQL login specifically is the problem. Go to your database → Query editor (preview) and run:
SELECT name, type_desc, is_disabled
FROM sys.database_principals
WHERE type IN ('S', 'E', 'X')
ORDER BY name;This shows all logins. If your login isn't there, you need to create it:
CREATE USER [yourusername] WITH PASSWORD = 'YourStr0ngPassword!';
ALTER ROLE db_datareader ADD MEMBER [yourusername];
ALTER ROLE db_datawriter ADD MEMBER [yourusername];Error 40532, Cannot open server: This almost always means the firewall blocked you. Go back to Step 3. But if TCP already tested fine, double-check that the server name in your connection string exactly matches what's shown in the portal, including capitalization and the full .database.windows.net suffix.
If your connection worked before but broke after an org-wide security change, check whether your admin enabled Azure AD-only authentication on the server. This disables all SQL logins. You'll find this setting under SQL server → Azure Active Directory → Support only Azure Active Directory authentication for this server.
Your connection works, but queries are slow. Azure SQL performance issues almost always fall into one of three causes: the service tier is too small for your workload, a query lacks an index, or statistics are stale. Let's diagnose each.
Check DTU or vCore consumption: In the portal, go to your database → Overview → scroll down to the Compute utilization chart. If you're consistently above 80% DTU or vCore usage, you need to scale up. Click Compute + storage in the left menu and bump up to the next tier. For unpredictable workloads, consider switching to the serverless compute tier, it auto-scales vCores between a configured minimum and maximum, and you only pay for what you use. This is one of the genuinely great features of Azure SQL Database that on-premises SQL Server simply can't match.
Check for missing indexes: Run this query in the Query editor to see what indexes Azure SQL's engine is recommending:
SELECT TOP 10
migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) AS improvement_measure,
mid.statement AS table_name,
mid.equality_columns,
mid.inequality_columns,
mid.included_columns
FROM sys.dm_db_missing_index_group_stats migs
JOIN sys.dm_db_missing_index_groups mig ON migs.group_handle = mig.index_group_handle
JOIN sys.dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle
ORDER BY improvement_measure DESC;Enable automatic tuning: Azure SQL Database has a built-in automatic tuning feature that can create and drop indexes automatically based on observed query patterns. Enable it in the portal: database → Intelligent Performance → Automatic tuning. Toggle CREATE INDEX and DROP INDEX to On. Microsoft's Azure SQL engine will start monitoring, and within 24–48 hours you'll typically see meaningful improvements on workloads with repetitive query patterns.
If the query sluggishness appeared right after a data load or a large batch operation, stale statistics are the likely cause. Run UPDATE STATISTICS [yourschema].[yourtable] WITH FULLSCAN; on the affected tables.
Advanced Troubleshooting
If the five steps above didn't resolve your Azure SQL issue, you're dealing with something deeper. Let's go further into the stack.
Reading Azure SQL audit logs and diagnostic data: Azure SQL can stream diagnostic telemetry to Azure Monitor, Log Analytics, or Event Hubs. If you haven't configured this yet, go to your database → Diagnostic settings → Add diagnostic setting. Enable SQLInsights, AutomaticTuning, QueryStoreRuntimeStatistics, and Errors. Send them to a Log Analytics workspace. Once data flows in (allow 5–15 minutes), you can run Kusto queries against the logs. To find all failed logins in the last hour:
AzureDiagnostics
| where ResourceType == "SERVERS/DATABASES"
| where Category == "SQLSecurityAuditEvents"
| where action_name_s == "DATABASE AUTHENTICATION FAILED"
| where TimeGenerated > ago(1h)
| project TimeGenerated, client_ip_s, server_principal_name_s, statement_s
| order by TimeGenerated descElastic pool misconfiguration: If you're using Azure SQL elastic pools to share resources across multiple databases and you're seeing one database go slow while others are fine, you're hitting resource starvation within the pool. In the portal, go to your elastic pool → Configure → Per database settings. Set a minimum eDTU (or min vCores) per database so that high-usage tenants can't starve low-activity ones. This is the key design lever for Azure SQL elastic pools in multi-tenant SaaS applications.
Managed Instance VNet peering and DNS issues: If your app runs in a different VNet than your Managed Instance, you need VNet peering configured correctly. Go to each VNet → Peerings and verify the peering status shows Connected on both sides. DNS is the other common failure point, Managed Instance requires that clients resolve the instance hostname using Azure-provided DNS. If your VNet uses a custom DNS server, you must add a DNS forwarder rule that sends *.database.windows.net queries to Azure's DNS at 168.63.129.16.
Migration compatibility issues (Azure SQL Database vs SQL Server): When migrating from on-premises SQL Server to Azure SQL Database, certain T-SQL features aren't supported. The most common surprises are: no SQL Server Agent jobs (use Azure Elastic Jobs instead), no linked servers (use external data sources or Azure Data Factory), and no USE [database] statements in scripts (Azure SQL Database is always single-database context). Use the Database Migration Assistant (DMA) to run a compatibility scan before migration, it flags every incompatible object.
Resource governance and connection pool exhaustion: Azure SQL Database enforces connection limits per service tier. If your app uses connection pooling badly (opening connections and never closing them), you'll hit the limit and new connection attempts will fail with error 10928 ("Resource ID: 1. The request limit for the database is X and has been reached"). The fix on the application side is to ensure every SqlConnection object is wrapped in a using block. On the Azure side, go to Compute + storage and increase the service tier, or switch to serverless compute which has a higher connection ceiling relative to cost.
If you've verified firewall rules, authentication, service tier sizing, and network configuration and you're still seeing intermittent errors, especially error 40613 ("Database on server is not currently available") or error 49918 ("Cannot process request"), these can indicate platform-level incidents. Check the Azure Service Health dashboard in the portal for your region first. If the health dashboard shows no incidents but your database is unreachable, open a support ticket with priority Sev-B at Microsoft Support. Have your Subscription ID, Resource Group name, SQL server name, and a time-stamped log of the errors ready, it cuts the triage time significantly.
Prevention & Best Practices
Fixing Azure SQL problems reactively is frustrating. Here's how to set things up so most of these issues never happen in the first place.
Use Private Endpoints from day one. Instead of relying on server-level firewall rules and public IP management, configure a private endpoint that connects your VNet directly to the Azure SQL logical server over Microsoft's backbone. Go to your SQL server → Networking → Private access → Create a private endpoint. This eliminates an entire class of public-internet firewall problems and gives you a stable private IP address that never changes.
Enable Azure Defender for SQL (Advanced Threat Detection). Microsoft's threat detection continuously monitors your Azure SQL databases for anomalous activity patterns, unusual query volumes, access from unexpected IPs, potential SQL injection attempts, and brute-force login attacks. Go to your SQL server → Microsoft Defender for Cloud and enable it. You'll receive email alerts for potential threats in real time. This is one of Azure SQL's genuinely powerful built-in security features, and it costs a flat $15/server/month, worth every cent for production workloads carrying sensitive data.
Configure geo-redundant backups and long-term retention. Azure SQL Database automatically creates backups, full backups weekly, differential backups every 12 hours, and transaction log backups every 5–12 minutes. But the default retention is only 7 days. For compliance and disaster recovery scenarios, go to your database → Backups → Retention policies and configure long-term retention (LTR) to store monthly or yearly backups in Azure Blob Storage. This satisfies most regulatory audit requirements without any custom backup scripting.
Right-size your service tier before going to production. The most common cost and performance mistake I see is picking a service tier at random during development and never revisiting it. Run your actual production workload (or a representative load test) and monitor DTU or vCore consumption for 48 hours using the Azure portal metrics. Then scale to a tier where your peak usage sits around 60–70% of capacity, that gives you headroom for spikes without overpaying for idle capacity.
- Enable automatic tuning (CREATE INDEX, DROP INDEX) on all Azure SQL Database instances carrying OLTP workloads, it's free and genuinely works.
- Set up Azure Monitor alerts for DTU/vCore > 80% and for failed logins > 10 in 5 minutes, you'll catch problems before users do.
- Use Azure SQL Database serverless tier for development and staging environments, it scales to zero when idle and you stop paying, which can cut dev/test Azure SQL costs by 60–80%.
- Always store your connection strings in Azure Key Vault and reference them via managed identity, never hardcode credentials in app config files or environment variables in production.
Frequently Asked Questions
What's the difference between Azure SQL Database and Azure SQL Managed Instance, which one should I use?
Azure SQL Database is the best choice for modern cloud-native applications where you want Microsoft to handle everything, patching, backups, HA, and you don't need full SQL Server feature parity. Azure SQL Managed Instance is the right pick when you're migrating an existing SQL Server application that relies on SQL Agent jobs, linked servers, cross-database queries, CLR objects, or other features that Azure SQL Database doesn't support. Managed Instance gives you almost 100% SQL Server engine compatibility inside a managed, VNet-integrated deployment. If you're unsure, run the Database Migration Assistant against your existing databases, it'll tell you exactly which product tier can host your workload without code changes.
I keep getting "Cannot open server requested by the login", how do I fix this?
Error 40532 almost always means the server-level firewall is blocking your IP address. Go to the Azure portal → your logical SQL server → Networking, and add your client's public IP as a firewall rule. If you're connecting from an Azure service, toggle "Allow Azure services and resources to access this server" to Yes. If it still fails after the rule is in place, check whether your client is behind a corporate proxy or NAT gateway, the egress IP seen by Azure may differ from your local IP. Run curl ifconfig.me from the machine or service that's connecting to confirm the actual outbound IP Azure sees.
How do I watch the "What is Azure SQL" beginner video Microsoft recommends?
Microsoft's official Azure SQL beginner video series lives on the Microsoft Learn platform. The introductory "What is Azure SQL" episode is episode 3 of 61 in the Azure SQL for Beginners series, it covers the three products in the Azure SQL family, when to use each, and how Azure SQL compares to running SQL Server yourself. You can also use the Azure SQL hub at aka.ms/azuresqlhub to explore decision trees and comparison tools that help you choose between Azure SQL Database, Managed Instance, and SQL Server on Azure VMs based on your specific requirements.
My Azure SQL database was fast yesterday and slow today, what changed?
The most common cause of sudden Azure SQL slowdowns without any application change is a statistics refresh on a large table that caused the query optimizer to pick a different, worse, execution plan. Run UPDATE STATISTICS [schema].[table] WITH FULLSCAN on your largest tables and check whether performance recovers. The second most common cause is a DTU or vCore spike from a new query pattern, check the Query Performance Insight blade in the portal (database → Intelligent Performance → Query Performance Insight) to see which queries started consuming the most resources. If you see automatic tuning recently dropped an index it previously created, that could also explain a regression, check the Automatic Tuning recommendations history in the portal.
Does Azure SQL automatically back up my database, and how long are backups kept?
Yes, Azure SQL Database and Azure SQL Managed Instance both perform automatic backups with no configuration required. Full backups run weekly, differential backups every 12 hours, and transaction log backups every 5–12 minutes, which gives you point-in-time restore capability to any second within your retention window. The default retention period is 7 days on most tiers, and you can extend it up to 35 days under the standard retention settings. For compliance scenarios requiring longer retention, go to your database → Backups → Retention policies and configure long-term retention to keep monthly or yearly backup snapshots in Azure Blob Storage for up to 10 years.
What is Azure SQL Hyperscale and when does it make sense to use it?
Azure SQL Database Hyperscale is a specialized architecture tier within Azure SQL Database that separates storage and compute into independently scalable layers. Unlike standard Azure SQL Database where storage and compute scale together, Hyperscale can handle databases up to 100 TB and scales storage automatically without downtime. It's built for workloads with very large datasets, fast backup and restore requirements (restore is near-instantaneous regardless of database size because it uses snapshot-based technology), or workloads that need read scale-out via readable secondary replicas without purchasing a separate geo-replica. If your database is under a few TB and doesn't need sub-second restore times, standard Azure SQL Database tiers will serve you fine at lower cost.