Whatsminer M60S – Temperature Too High

Power the M60S off at the PDU or breaker (hard cut, not a soft shutdown) and wait 15 minutes. Cooling a miner that tripped TEMP_OVER before you restart it prevents you from immediately re-tripping on residual heat. While you wait, confirm the intake grille has at least 15 cm of clearance in front of it and that nothing is recirculating exhaust back into the intake - a common home-rack mistake.

Measure intake air temperature with an IR thermometer pointed at the front grille, not the room air mid-floor. Target is 30 C or below for standard-air M60S and 40 C or below for hydro variants. Record the number - you will compare this against what the miner reports in step 7 to catch a lying sensor. If intake is hot, fix the room first (ducting, AC, relocation) before proceeding.

Using WhatsminerTool or an SSH / API call to TCP 4028, pull the exact error-code payload. Separate environment codes (600/610) from hashboard codes (350-352) from PSU-side codes (233-235 / 243-245). The code identity tells you which subsystem to chase - do not assume all three mean the same thing. Note the code number before you reboot, because some codes clear on restart and hide the diagnosis.

Reboot the miner via the web UI or a 30-second hard power cycle. Watch the first 10 minutes of operation - if the code returns in under 2 minutes, the trigger is still present (skip ahead to step 6). If it runs clean for 10+ minutes then trips again, you are chasing a thermal-cycling or warm-up fault (continue to step 5).

Blow compressed air across the intake grille, then through the heatsink fin stack from the intake side pushing dust OUT the exhaust - never the reverse direction, which packs dust deeper into the fin pack. Do the fan blades, the PSU intake, and the small button board area near the control board. If you find a dust mat thicker than roughly 1 mm anywhere, you likely just found your root cause - reboot and observe.

Verify both hashboard fans and the PSU fan are spinning at matched RPM within 10% of each other and within 10% of nameplate (~6000 RPM at full duty on M60-class). With the miner off, spin each fan by hand - resistance should feel equal. Power on and log fan0 / fan1 values from the API. A fan running 20% below its pair under the same duty command is dying - swap it before chasing deeper problems.

Cool-room-hot-code test. If your measured intake is 24 C and the miner still reports environment temperature high (600/610), the environment sensor on the button board is suspected faulty. Power off, open the chassis, locate the button board (small PCB ~40 x 20 mm near the control board carrying the env sensor plus the IP-report button), reseat its ribbon cable. If the code persists after reseat, the sensor has drifted or died - order a replacement from Zeus, BiXBiT, or the D-Central parts bench. Swap is a sub-30-minute job at a bench.

Firmware version audit. Read the running firmware version from MinerTool. If you flashed forward recently on M60-class, the escalation-threshold change in post-20230101 builds may be tripping TEMP_OVER on readings that used to be warning-only. Rolling one version back is a valid diagnostic, but ONLY to a MicroBT-authorized build. Never downgrade across the post-20240601 signature-verification wall - that is a documented hard-brick path (see: Whatsminer M60S - Firmware Rollback Failed).

Under-load PSU rail check. Multimeter on DC, probe at the PSU output under full hashing load. Expect steady DC output within the M60-class tolerance band (verify against your firmware revision's service notes - MicroBT does not publish per-model voltage tolerances). If output is sagging at load, the PSU is tiring and feeding heat back into its own sensor (codes 243-245). Swap the PSU before chasing more thermal fixes - a tired PSU manifests as a thermal code about 30% of the time in D-Central's repair queue.

Per-hashboard temp spread diagnostic. Let the miner run 10 minutes at full hash, then log SM0 / SM1 / SM2 via API. Healthy M60S: all three within 5 C of each other, peak 80 C or lower. If one board reads 10 C or more above its neighbours, that board has a paste / pad / chip-level issue. Mark it, then move to step 11 (paste refresh) before going deeper.

Thermal paste refresh on the hot hashboard. Remove the heatsink (standard M60-class chassis fasteners), clean old paste with 99% isopropyl and lint-free wipes (do NOT use paper towel - fibres contaminate the joint), inspect thermal pads on PMIC and voltage-domain ICs for crumbling, apply a uniform thin layer of Arctic MX-6 or Thermal Grizzly Kryonaut to each chip, replace any crumbled pads with thickness-matched Gelid GP-Extreme pads, reassemble with consistent torque. Run 20 minutes and re-check the SM spread from step 10.

Busbar torque check on the PSU side (codes 233-245 specifically). Power off, disconnect input. With an insulated torque wrench check each busbar nut - community consensus is 4-5 N.m for M60-class though MicroBT publishes no official spec. A loose busbar creates a high-resistance joint that dumps heat exactly where the PSU sensor sits, producing a phantom thermal code when the real fault is electrical. IR-scan the busbar junctions after retorque - a lingering hot spot means the copper is pitted and the lug needs replacement.

Button-board sensor replacement. If step 7 pointed here, order the replacement part (sub-$45 CAD), power off, open the chassis, disconnect the button-board ribbon, unscrew and swap. Reconnect, close chassis, power on and verify the env temp reading now matches your IR thermometer within 2 C. This single swap resolves the majority of cool-room-hot-code false-positive tickets D-Central sees on M60-class hardware.

Controlled firmware flash to an authorized build. ONLY attempt this if you have verified the signature wall position of your hardware revision and the target build. Use WhatsminerTool's firmware upgrade workflow, not a third-party tool. Post-flash, run a 30-minute baseline at nameplate hashrate with the miner on a known-good thermal setup, and log whether TEMP_OVER returns. If the flash itself fails or bricks the unit, stop - that is a Tier 4 JTAG-recovery ticket.

Stop DIY and book D-Central repair. You have reached Tier 4 when any of the following is true: per-board temp spread stays wide after full paste/pad refresh (chip-level fault), visible capacitor or component damage anywhere, PSU shows internal burn or recurring thermal trip within 48 h of clean start, or a firmware flash went sideways and the miner will not boot. From this point, a bench with a test fixture and official MicroBT test binaries is worth more than another Saturday afternoon of Google searches.

Bench process at D-Central for M60-class TEMP_OVER tickets: per-board isolation on the test fixture with programmable load, SMT chip probing to find the failing chip position, salvaged-grade replacement from M60-class chip inventory when needed, full paste and pad refresh, PSU internal inspection and component-level repair where possible, and a 24-hour burn-in at nameplate hashrate before ship-back. Typical Canadian turnaround 5-10 business days; international 10-15.

Ship-to-repair packing. Pack the whole unit (or the hashboards alone for board-only tickets) in anti-static bags, double-box with at least 5 cm of foam on every side of the inner carton, include a note with: observed symptoms, exact error code, firmware version, power environment (120 V / 208 V / 240 V), and your contact info. This saves diagnostic time at the bench, which saves you money on the repair invoice.

Post-repair monitoring. When the miner returns, configure alerts for: per-board SM spread above 5 C, environment sensor above 35 C, PSU exhaust above 55 C, and any single fan RPM dropping more than 10% from its 7-day baseline. Any of these four catch a brewing TEMP_OVER before the hard trip. WhatsminerTool + a basic polling script on the TCP 4028 API is enough - no paid monitoring service required.