Free
Cluster Issues?
The free first step after a cluster incident. One read-only script across your Hyper-V, HCI or Azure Local environment. You receive the triage list: the five heaviest signals around your incident window, sorted by severity. Free, without subscription and without obligation.
Example of the form; the content comes from your own measurement.
How it works
Request the script
Fill in one short form. You download the script with its instructions straight away.
Run it from your management server or cluster node
It only reads: the event channels of all nodes over the incident window. It first shows the plan of the run, with one yes-or-no question. Memory dumps stay out of scope in this free variant.
Hand over the output
You upload the one encrypted zip it leaves in your browser. Confirm your e-mail address and the result opens in the portal.
You receive the top-5 likely culprits.
Request
A few details are enough: the cluster, whether it is still running, what happened and how far back to look. You download the script at once, without waiting for us.
The form opens in the ClusterTriage portal, on our servers in the EU. No password: we send a button to your work address.
Is the cluster completely down? The portal first shows how to bring it back, one node at a time.
Rather talk to someone? WhatsApp or e-mail hans@clustertriage.com.
What the triage list is, and is not
What you get
Five signals, sorted by severity, each with the measured value, the node and the timestamp. Whatever could not be read is listed too, with the reason.
What it is not
No cause and no reconstruction: triage sorts, the diagnosis takes deeper investigation. No report, no review session, and no subscription attached.
More than five found? The triage list also states the total number of signals found; the five heaviest are always in this free list.
Safe and read-only
- Nothing is installed and nothing is changed; nothing is left behind afterwards.
- No passwords are processed or stored. Before the file is written, the script checks its own output for values that look like credentials.
- Memory dumps do not travel in the free variant.
- What you hand over is used solely to produce the triage list.
If the list points at something
Triage sorts the signals, it does not explain them. When the list points at a real problem, the next step is a proper root-cause investigation: the reconstruction across all nodes, with timeline, gaps and an RCA document.
If the environment has never been measured end to end, that investigation is strongest combined with a baseline assessment through ClusterTriage Assurance: the same specialists, a read-only method, and a report built from measured state rather than a checklist.
Compared with the free Microsoft tools
Windows already ships tools for a cluster incident. They are good at what they do; triage fills the gap between them.
| Tool | What it gives you | Where it stops |
|---|---|---|
Get-ClusterLog | The cluster debug log of every node, for a time span you choose | Raw text per node, often thousands of lines; you correlate the nodes and judge the severity yourself |
Test-Cluster (cluster validation) | Whether hardware, network, storage and configuration are supported | Tests the configuration as it is now, not what happened in the incident window; its storage tests are best kept off a cluster in production |
| Event Viewer and Failover Cluster Manager | The event channels, filterable per node or per cluster | No ranking across nodes and channels; finding the five events that matter is up to you |
| ClusterDown triage list | The event channels of all nodes over the incident window, read-only, the five heaviest signals sorted by severity, with node and timestamp | Sorts the signals and names what could not be read; it does not determine the cause |
Triage by hand: the commands
Without any extra tool, these built-in PowerShell commands narrow down a failing Windows Failover Cluster. Run them from a node or a management server with cluster rights. All of them only read.
Get-ClusterNode: are all nodes Up? A node that is Down or Paused is the first lead.Get-ClusterQuorumandGet-ClusterResource: is the witness reachable, and which resources are offline or failed, on which node?Get-ClusterSharedVolume: is every Cluster Shared Volume online, and is any of them in redirected access?Get-WinEvent -FilterHashtable @{LogName='System'; Id=1135,1177,5120}on each node: event 1135 means a node was removed from membership, 1177 that quorum was lost, 5120 that CSV I/O was paused. Note the times and compare them across nodes.Get-ClusterLog -TimeSpan 60 -UseLocalTime -Destination C:\Temp: writes the cluster debug log of every node for the last 60 minutes. Read it around the times from step 4.Test-Cluster -Ignore Storage: validates network, inventory and configuration without touching the disks. Keep the storage tests off a cluster in production.
Do not force quorum (-FixQuorum) unless you know why it was lost. ClusterDown runs these reads across all nodes at once, over the incident window, and returns the five heaviest signals sorted by severity, with node and timestamp. It sorts the signals; it does not determine the root cause. Request the triage script.
Recognise this?
What Cluster Triage is for
These sentences come from findings written down in real engagements. If you recognise one, the triage list is the first step: it sorts the problem before you start searching.
Cluster and nodes
- Cluster is down
- Cluster node keeps failing
- Node not added to the cluster
- Cluster went down during patching
- Cluster went down twice last weekend
- Bluescreen on a cluster node
- No crash dump after an outage
- Event 1135: node removed from the cluster
- Cluster validation reports errors
Quorum and storage
- Quorum lost
- Witness unreachable
- Storage Spaces Direct volume degraded
- S2D repair job does not finish
- CSV went offline
- Cluster Shared Volume in redirected mode
- Event 5120: CSV I/O pause
- High latency on storage
- MPIO path lost
Network and migration
- Live migration fails
- Live migration is slow
- RDMA does not work
- Virtual machines unreachable after a restart
- VM freezes randomly
Azure Local and backup
- Azure Local update fails
- Solution update hangs
- Readiness check failed on Azure Local
- Backup fails on the cluster
- Veeam backup on the cluster is slow
If your situation is not listed, triage is still the safest first step: it only reads and changes nothing. What is needed after that emerges from the list.
Frequently asked questions
Is ClusterDown really free?
Yes. The script and the triage list with the five heaviest signals are free, without subscription and without obligation. A root-cause investigation or an assessment afterwards is a separate choice.
What does the script change on my cluster?
Nothing. It only reads the event channels of the nodes over the incident window, shows the plan of the run first with one yes-or-no question, installs nothing and leaves nothing behind. No passwords are processed or stored.
How is this different from Get-ClusterLog or Test-Cluster?
Get-ClusterLog gives you the raw log of each node and Test-Cluster checks whether the configuration is supported. The triage list reads all nodes over the incident window and sorts the five heaviest signals by severity, so you know where to look first. See the comparison.
Which environments does the triage cover?
Classic Hyper-V failover clusters, Azure Stack HCI and Azure Local, with SAN (iSCSI or FC), SMB3, Storage Spaces Direct or local storage.
What comes after the triage list?
When the list points at a real problem, the next step is a root-cause investigation. ClusterDown is the free, read-only triage after an incident: it sorts the five heaviest signals and does not determine the cause. ClusterTriage is the independent cluster assessment, once or as the yearly Assurance cycle, that diagnoses risk and verifies remediation.
Is your cluster down?
Do not wait until the evidence is gone
Request the read-only triage script. You receive the five heaviest signals free of charge and know which next step makes sense.