Every Antminer talks to you through two board-mounted LEDs — a red fault light and a green normal light — plus the link/activity pair on the RJ45 network jack. Learn to read them and you can triage most field problems in seconds, before you open a browser. This guide decodes every LED state across the 15, 17, 19, 21 and later Antminer series — what each pattern means and the next diagnostic step for each fault.
The Two Status LEDs: Where They Are and What They Do
On air-cooled Antminers the two status LEDs sit on the control board, visible near the network port. The green LED is the “normal” (running) indicator; the red LED is the “fault” indicator. They are driven by firmware, so their pattern reflects what the software thinks is happening — which is why a misleading LED almost always points at a firmware, pool, or network condition rather than a dead component.
Hydro and immersion units differ. Fanless liquid-cooled models show the same control-board LEDs, but there is no fan-fault branch to chase — a “Fault 1” on an immersion rig means temperature or network, never a seized fan. Treat the pump and coolant flow as the equivalent of the fan on an air unit.
Normal Boot Sequence (17-series example)
Watching the boot is the fastest health check — a healthy Antminer walks through three stages:
- Power-on / initialization — both LEDs light solid together while the control board boots and enumerates the hashboards.
- Pool connect — the green LED goes out and the red LED flashes as the miner negotiates with the configured pool.
- Hashing — the pool accepts, the red LED goes out, and the green LED flashes. Hashrate is reporting. This is the steady-state “all good” pattern.
If the LEDs stall at stage 1 or 2 for more than a few minutes, use the fault table below.
Fault-Light Reference (operating state)
During operation the red (fault) and green (normal) LEDs encode the miner’s condition. Read them together:
| Red / Fault | Green / Normal | Meaning |
|---|---|---|
| Off | Flashing | Normal — hashing and reporting |
| Flashing | Off | Fault 1 |
| Solid on | Off | Fault 2 |
| Off | Solid on | Fault 3 |
| Off | Flashing | Fault 4 |
| Flashing | Flashing | Fault 5 |
“Normal” and “Fault 4” share the same pattern (red off, green flashing) — under Fault 4 the miner runs but under-performs, so always cross-check the LED against actual hashrate.
Fault 1 — miner stopped hashing
The most common catch-all fault. Work the three usual causes in order:
- Temperature protection. Over- or under-temp halts hashing. Check inlet/outlet temps, confirm ambient isn’t above the model’s rated intake, and verify airflow is unobstructed (or, on hydro/immersion, that the pump and coolant flow are live).
- Network. A miner that idles because it lost its pool often surfaces here — confirm it still has an IP and can reach the pool. (Firmware idles on pool loss; it does not run at full power into a dead connection.)
- Fan. A dead or stalled fan trips fan-fault protection. Air units report per-fan RPM — any fan reading 0 RPM is the culprit. Does not apply to fanless liquid units.
Fault 2 — pool / configuration failure
The miner booted but cannot mine:
- Pool config. Verify the stratum URL, port, and worker name are correct and the pool is up. A typo in the URL or a stale port is the top cause.
- Firmware. If the config is clean, reflash the control board with the manufacturer’s official signed image for that exact model. Never flash an image built for a different model or an unsigned build.
Fault 3 — network abnormal
- High latency / packet loss between miner and pool. Ping the pool from a machine on the same subnet.
- IP conflict or bad addressing. Two devices on one IP, or a DHCP collision, will strand the miner. Assign a static lease, or use the manufacturer’s IP-reporter (the miner answers a broadcast to announce its address) to confirm the IP it holds.
Fault 4 — control board suspect
Running but degraded. First try an SD-card recovery flash with the correct signed image to rule out corrupted firmware. If the board still misbehaves after a clean reflash, it is a hardware fault — replace the control board.
Fault 5 — low hashrate
Both LEDs flashing signals output has fallen below expectation. Common causes: network latency throttling accepted shares, a de-rated hashboard, or a chip fault on one domain dragging the board down. Check the dashboard for a hashboard reporting fewer than its full chip count, then work per-board — the S9 uses per-board power connectors, while S17/S19/S21 hashboards feed from a bolted bus-bar, so a loose seat presents differently by generation.
Locate / Blink: Finding One Miner in a Rack
To identify one unit among dozens, the firmware can strobe both LEDs on demand.
- 15 / 17 series: log in, open System → Locate, and click Start Blink — both LEDs flash together for 300 seconds or until you press Stop Blink.
- 19 series and later: log in and toggle the Locate Miner control (top-left; green when active) to flash both LEDs; toggle it grey to stop.
The Network-Port LEDs
The RJ45 jack carries its own pair: one for link (a connection to the switch) and one for activity (data passing). Colour assignment varies by model, but the states are consistent:
- Normal: the link LED is steady and the activity LED flashes with traffic.
- Both dark: no link. Re-seat the cable at both ends and swap in a known-good one; confirm the switch port is powered and up (try another port); if a good cable into a live port still yields no link, the control board’s PHY may be damaged and the board needs repair or replacement.
Common Mistakes and When to Escalate
- Trusting the LED over the dashboard. Fault 4 and Normal share a pattern — always confirm against real hashrate.
- Flashing the wrong firmware. Only ever use the official signed image for the exact model; a mismatched or unsigned build can brick the control board.
- Chasing a fan fault on a fanless unit. Hydro and immersion miners have no fans; their thermal fault is a pump/flow problem.
If a clean reflash with the correct signed image will not clear a Fault 2/4, or the network LEDs stay dark through a known-good cable and port, you are into control-board or PHY-level hardware — bench work. A persistent Fault 5 with a hashboard short on its chip count is a board-repair job, not a config fix.
Related: Match a specific fault to its fix with the ASIC fault finder, source control boards, fans and PSUs from the ASIC repair parts catalog, or hand the unit to the bench through start a repair.
