Fault-Triage: Isolate Before You Swap

Classify the fault first

Every triage starts with one question: what CLASS of fault is this? Nail the class and the rest is a checklist. Guess it and you start pulling good parts.

• Whole-unit-down: no power, no web UI, no API - nothing answers. Suspect power or the control board.
• Board-down: the unit is up and reachable, but one chain reads 0 chips (e.g. 'chain finds 0 asic'). One board missing, the rest still hash.
• Degraded: full chip count, all boards present, but average hashrate sits below rated. Nothing flags as failed - it is quietly throttled.

Work causes cheapest-and-commonest first

Once classified, chase causes in cost order. The cheapest, most common fix goes first; opening an RMA goes last. Skipping the order is exactly how a good board lands in the RMA pile.

1. Power - qualified verification of the exact PSU, supply voltage/phase and cabling against model/nameplate requirements; no live reseating.
2. Network / config - pool URL, worker name, IP, DNS.
3. Hashboard / ribbon SEATING - reseat the data ribbon AND the board power connectors.
4. Thermal - dust, blocked airflow, dried paste.
5. Then and ONLY then - swap the board or open an RMA.

Signature -> class -> first move

Most complaints have a signature that maps straight to a class and a first move. Match the signature, skip the guessing.

Where this fits

Fault-triage is the decision framework, not another code list. It tells you WHICH reference to reach for and in what order.

• The per-family code tables (Whatsminer numeric, Antminer kernel-log strings) tell you what a specific code means - after triage says which class you are in.
• The Diagnose log-matcher parses a pasted log into a likely cause - use it once you have isolated to board or thermal.
• Triage sets the order; the code tables and the matcher fill in the detail.