PWAIT_HADR_WORKITEM_COMPLETED is recorded by a thread waiting for an asynchronous Availability Group work task to complete. AG management operations frequently hand their real work to async tasks, adding a database to an AG, removing one, joining a replica, and the initiating thread parks in this wait until the work item reports back.
Expected during any such operation; the duration should match the operation’s natural runtime.
Is It a Problem?
Short-lived appearances during AG changes are the mechanism working. The failure mode to know: if this wait accumulates on one thread for a very long time, the underlying async operation has stalled, and there are known cases of removing a database from an AG hanging indefinitely with exactly this signature. At that point you have a wedged AG operation, not a slow one.
Duration relative to the operation’s normal cost is the whole diagnostic.
Common Causes
- Normal async AG operations in flight (database add/remove, replica joins).
- A stalled work item, blocked behind cluster issues, a wedged database state, or a bug, holding the initiator forever.
What To Do
- For a long-running AG command, check what the async side is doing: AG DMVs for the database/replica states involved, the error log, and the cluster log for the same window.
- Genuinely wedged operations usually need the initiating session killed and the state cleaned up; if the hang reproduces, capture details and check your build’s fix list.
- Do not stack retries behind a stalled operation; resolve the stall first.
How To See It
Rank it against everything else with Get-WaitStatistics; occurrences map one-to-one onto AG management activity, and outliers in duration are the signal.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply