Always On Availability Groups Troubleshooting
Always On Availability Groups fail quietly, most of the time. A replica falls behind, nobody notices for three weeks, and then a real failover happens and the "standby" wasn't actually caught up. Here's where to actually look, in the order that finds problems fastest.
1. Start with the dashboard, but don't trust it blindly
SQL Server Management Studio's Always On Dashboard is the fastest first look — it'll show synchronization state, failover readiness, and estimated data loss at a glance. But it's a snapshot, not a monitor. If you're only checking it when something already feels wrong, you're already behind. Pair it with the DMVs below for anything you actually depend on.
2. The four DMVs that tell you what's really happening
sys.dm_hadr_availability_replica_states— replica-level health: synchronization state, connected state, operational state. Start here.sys.dm_hadr_database_replica_states— the one that actually matters for data loss risk:log_send_queue_sizeandredo_queue_sizetell you how far behind a replica really is, in KB, not vibes.sys.dm_hadr_availability_group_states— group-level state including primary recovery health and synchronization health.sys.dm_hadr_cluster_members— Windows Server Failover Cluster member state, useful when the AG looks healthy but the cluster underneath is not.
3. Common failure patterns and what they actually mean
| Symptom | Likely cause |
|---|---|
| Replica stuck in "Not Synchronizing" | Network interruption, or the replica was manually taken offline and never resumed. Check the AG dashboard's "Not Synchronizing" state directly. |
| Growing log_send_queue_size | Network throughput can't keep up with transaction log generation rate — usually a large batch job or index rebuild flooding the log. |
| Growing redo_queue_size on secondary | Secondary replica's redo thread can't keep up — often a single-threaded redo bottleneck on a busy primary, worth checking secondary hardware/IO. |
| Automatic failover doesn't happen | Check the availability mode — automatic failover requires synchronous-commit mode AND a healthy quorum. Asynchronous replicas never auto-failover, by design. |
| Listener unreachable after failover | DNS caching on client machines, or the listener's IP resource didn't come online on the new primary's subnet — common in multi-subnet AGs. |
4. Test failover before you need it — for real, not in theory
A tested failover means: pick a maintenance window, fail over manually, confirm the application actually reconnects (not just that SQL Server says the failover succeeded), and fail back. If your DR plan says "we'd fail over" but nobody's actually done it in the last six months, you don't know if it works. AGs are one of the areas where the gap between "configured" and "actually functional" is widest.
5. The listener is usually where multi-subnet failovers actually break
The availability group listener is a virtual network name — and virtual network names have DNS propagation delay. In multi-subnet configurations, a failover can succeed at the SQL Server level while client applications keep trying to connect to the old IP for minutes afterward because of DNS TTL. If failovers are "successful" but applications don't reconnect promptly, check listener DNS TTL settings before assuming it's an application bug.
6. Set up real alerting, not just the dashboard
- Alert on
redo_queue_sizeandlog_send_queue_sizeexceeding a threshold that matters for your actual RPO — not an arbitrary default. - Alert on synchronization state changes, not just failures — catching "Synchronizing" (in-progress recovery) early is better than catching "Not Synchronized" late.
- Monitor the underlying Windows Server Failover Cluster health separately — AG health and cluster health can diverge, and cluster-level quorum issues are often the root cause of AG problems that look unrelated.
The failures that hurt aren't the ones where the AG goes red and pages someone. They're the ones where a replica quietly falls three days behind, nobody's watching the queue size, and the "safety net" wasn't actually there when it mattered.
Dealing with an AG that's not behaving?
Free 20-minute fit call — bring the symptoms, get a straight read on where to look.
Book a free fit call