When reviewing availability events on SQL Server, one of the first questions is often:
Did the cluster move, and when?
This post shows how to use PowerShell to retrieve the last Windows Failover Cluster role movement for a SQL Server instance by querying cluster event logs. It’s a fast, reliable way to confirm node-level failovers during incidents, patching, or unplanned outages.
What This Method Shows (and What It Doesn’t)
This approach reads Windows Failover Clustering events, not SQL Server metadata.
It tells you:
- When a clustered role moved between nodes
- Which node became active
- That the failover was handled by the cluster
It does not tell you:
- Which Availability Group failed over
- Which databases changed primary
- Whether the failover was automatic or manual at the AG level
That distinction matters in Always On environments, where node movement and replica role changes are related but not always the same event.
Get Last SQL Cluster Failover Time with PowerShell
Cluster role movements are recorded in the FailoverClustering Operational log. Event ID 1641 indicates a clustered role has moved.
Update ListenerName to your SQL Server or Availability Group listener name before running the command.
# Get last SQL Server cluster role failover time
Get-WinEvent -ComputerName ListenerName `
-FilterHashtable @{
LogName = 'Microsoft-Windows-FailoverClustering/Operational'
Id = 1641
} |
Format-Table TimeCreated, Id, Message -AutoSize -WrapThis returns the most recent cluster-level failover events, including timestamps and node movement details. Because the data comes from the cluster, it remains available even if SQL Server itself was briefly offline.
Cluster Failovers vs Availability Group Failovers
These are related but not the same thing.
A cluster failover means the Windows Failover Cluster moved the SQL Server role, usually due to node failure, reboot, patching, or cluster health checks. These events are always visible in Failover Clustering logs.
An Availability Group replica failover means the primary replica changed to another node. This can occur without a cluster role move and is recorded inside SQL Server, such as in logs, DMVs, or Extended Events. It may be automatic or manually initiated.
In short:
A cluster failover always involves the cluster. An AG failover does not always involve the cluster.
This PowerShell method confirms node-level movement only, not database-level replica changes.
When This Check Is Useful
This check is most useful when you need to confirm whether a server actually failed over, validate the timing of unplanned node transitions, review patching or reboot activity, build an incident timeline, or understand why SQL Server was briefly unreachable.
For Availability Group failover timing or database role changes, SQL-based checks are more appropriate.
Final Notes
This is a deliberately narrow check.
It answers one question clearly: when the cluster moved the SQL Server role. It does not attempt to infer Availability Group behaviour or database impact.
Used correctly, it helps separate cluster events from SQL-level failovers, which keeps investigations focused and avoids chasing the wrong signal.
Leave a Reply