HADR_CLUSAPI_CALL is recorded when a SQL Server thread switches to preemptive mode to invoke Windows Server Failover Clustering (WSFC) APIs. Availability Groups lean on the cluster constantly, health reporting, lease maintenance, metadata reads, failover coordination, and each of those calls leaves SQL Server’s cooperative scheduler while Windows does the work.
On any AG-enabled instance this ticks along in the background as a matter of course.
Is It a Problem?
Normally no; it is filtered as benign, and steady low-level accumulation just means the AG plumbing is talking to the cluster as designed. The situation that changes the reading is cluster distress: if WSFC itself is slow or struggling (quorum issues, a wedged cluster service, RHS problems), these calls stretch, and unusual growth here can accompany AG lease timeouts and failovers.
So: ignore it day to day, but glance at it when you are doing a post-mortem on an unexpected AG failover.
Common Causes
- Routine AG-to-cluster communication (health, lease, metadata).
- Cluster service or quorum problems stretching API calls, in incident scenarios only.
What To Do
- Filter it from routine analysis; our
Get-WaitStatisticsscript already does. - During AG incident review, check the cluster log and Windows event logs alongside any anomaly in this wait; the story will be in WSFC, not SQL Server.
- Do not tune anything based on this wait alone; there is no SQL-side knob for it.
How To See It
Rank waits with Get-WaitStatistics; expect it filtered. Its diagnostic value is limited to corroborating cluster-side trouble during incidents.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply