Almost every ASIC miner has a single bi-colour status LED — green for “healthy,” red for “fault” — plus the two small lights on the Ethernet jack. That light is a coarse state signal, not a precise error code: it tells you which subsystem to look at, not exactly what failed. Here is what the common patterns mean across the major makers, and where to go for the specifics.

How an ASIC signals a fault with a light

The front-panel status LED is driven by the miner’s control board after the kernel reaches userspace. On a Bitmain Antminer the board carries a two-LED strip — a green “normal” lamp and a red “fault” lamp wired to separate GPIO lines — and the firmware asserts whichever flag is active. MicroBT, Canaan and most open-source boards (D-Central’s own BCB100 control board uses a green LED on PA10 and a red on PF7) follow the same idea: a tiny number of visible states standing in for a much larger internal fault table.

That compression is the whole point. The firmware may track dozens of distinct error codes, but the LED has to communicate to a human standing in front of a 3.5 kW box wearing ear defenders. So everything collapses down to roughly four states: off, solid, slow blink, and fast blink, in one or two colours. The exact colour-and-cadence mapping differs by maker and even by firmware build — do not assume a Whatsminer pattern means the same thing on an Avalon.

The two lights you are also ignoring: the RJ45 jack

The Ethernet connector has its own pair of LEDs, and these follow the universal PHY convention rather than any miner-specific scheme. The link LED (usually solid green or amber) means the physical link negotiated — cable, switch port and PHY are alive. The activity LED (blinking) means packets are actually moving. A dark link LED is a dead cable, port or PHY before you ever reach a software problem; a solid link LED with no activity flicker means the miner has a link but isn’t talking. On a “green status LED but no shares” call, the RJ45 lights often diagnose it in two seconds.

The light is a pointer, the log is the diagnosis

The single most important rule on this page: the status LED narrows the fault to a bucket; the web UI, on-screen message, or numeric log code names the exact cause. Catch the pattern, then read the dashboard or pull the log. Photograph or video the LED while the fault is live — the instant you reboot, the state resets and you lose the evidence.

The universal LED state map

These are the patterns that hold across makers. Where a maker has a documented, verified meaning we link the exact code page; where it is maker-specific we say so.

What you see	What it generally means	First action
Status LED off while the PSU fan is running	Control board has no power, isn’t booting, or the LED rail itself is dead — not a mining fault yet	Confirm PSU output and reseat the control-board power lead. See no-LED / won’t-power-on.
Solid green	Control board booted and firmware reports “normal.” This is proof the kernel is alive — not proof the miner is hashing	Verify real pool shares. Green with 0 TH/s is a known trap: green LED, no hashing.
Blinking green (Antminer ~2 Hz)	Healthy run state on Bitmain — stratum bound and submitting work	Nothing. This is the target state; confirm hashrate matches nameplate.
Solid red	Hard fault — the miner halted before silicon damage (hashboard absent, fan lost, thermal limit, PSU handshake lost)	Power-cycle 60 s, then read the UI. Antminer: solid red fault LED.
Fast red blink (~2–4 Hz)	Critical, unrecoverable without intervention (MicroBT). Board stopped trying	Pull logs, grep for fault codes. Whatsminer: fast red blink.
Slow red blink (~1 Hz)	Warning — chips alive, network/pool/config not (MicroBT). Recoverable	Check DHCP, DNS, pool string. Whatsminer: slow red blink.
Alternating red/green	Non-fatal warning while still hashing (Bitmain) — both flags asserted at once	Read the UI; the named fault is already there. Alternating red/green.
White / blue rapid flash then yellow then green (Avalon)	Normal boot sequence: bootloader → init → healthy. Stuck on white past ~60 s = OS didn’t boot; stuck yellow past ~5 min = init failed	Time the sequence from a cold boot. Avalon: Avalon LED patterns.
Multi-LED block (e.g. four lights D1–D4)	Each light maps to a subsystem (power / network / hash / alarm); the combination is the code	Match the official pattern table, then the log. IceRiver: D1–D4 codes.
Red & green both stuck on / rapid LED cycling	Boot loop or interrupted firmware flash — the board never finishes booting	Recovery reflash. Goldshell stuck LEDs · Bitaxe boot loop.
Red LED on the PSU itself	Power supply fault — over-temp, over-current, fan stall, or rail out of window	Diagnose at the PSU, not the miner. APW12 red LED faults.

What each maker actually publishes

The catch is that the makers document these lights badly, which is why operators guess. Here is the verified state of each, with the gaps named honestly.

Bitmain Antminer

Bitmain’s signal-light article documents only steady states — startup both LEDs on, pool-connected green flashing, red off. It never published a blink-count-to-fault table, so the alternating red/green warning state and the deceptive solid-green-but-idle state are undocumented. Treat green as “kernel booted,” red as “halted,” and read kern.log / the Miner Status page for the actual cause.

MicroBT Whatsminer

MicroBT ships an 80-code error PDF and a full tool stack but no LED chart — just one FAQ line, “red flashing = high-temp or network down.” Two different root causes collapsed into one state. The real differential is in the cadence: fast red is critical, slow red is a network/config warning. Our Whatsminer LED reference maps each pattern to its log code.

Canaan Avalon

An Avalon has two lights — the chassis LED on the lid and the AUC controller LED — and they mean different things. The chassis LED walks white/blue → yellow → green on a healthy boot; a sustained red lumps seven distinct faults (over-temp, loopback fail, PG fail, core-test fail, voltage error, temp-sensor error, no fan) into one colour with no blink code. The decoder lives in the cgminer API output and log, not the light — see Avalon LED disambiguation.

IceRiver, Goldshell and open-source boards

IceRiver uses a four-LED block (D1–D4) where the combination encodes the bucket — D2 alone is healthy, D1+D3 is a fan fault, D1+D2 is network, D2+D3 is overheat (note: IceRiver is a Kaspa ASIC, not Bitcoin). Goldshell’s two LEDs stuck red-and-green means an interrupted flash. Open-source boards (Bitaxe and kin) typically expose a single addressable LED plus an OLED/LCD status screen, where the on-screen message — not a blink code — is the real diagnostic; rapid LED cycling there usually signals a boot loop.

The general LED diagnostic ladder

Regardless of maker, work the light in this order:

1. Capture the state. Photograph or take a 5-second video of every LED — status light and RJ45 — while the fault is live, before you touch anything.
2. Check power first. Status LED fully off with the PSU running is a power/boot problem, not a mining fault. Confirm PSU output and reseat the control-board lead before anything else.
3. Read the RJ45 lights. No link LED = cable/switch/PHY. Link but no activity = the miner isn’t reaching the network. This clears most “looks alive but no shares” calls.
4. Bucket the status LED using the table above: off, solid green, blinking green, solid red, fast red, slow red, alternating, multi-LED, or boot pattern.
5. Open the web UI / on-screen message. The named warning string or display message is the real diagnosis the light is pointing at.
6. Pull the log and match the numeric code. LED bucket + exact code = unambiguous fix path. Look it up in the ASIC Fault Finder (650 indexed codes).
7. Cold power-cycle 60 seconds only after you’ve recorded the state — a full discharge clears a wedged fault from a brownout or mid-flash reboot, but it also erases the evidence.

DIY versus the bench — and when to send it in

Plenty of LED faults are owner-fixable: a slow-red network blink is a DHCP, DNS or pool-string fix; a solid-green-no-hash is often a dead control-board clock battery or a factory test pool; a red PSU LED is frequently a stalled fan or a tired capacitor you can identify before swapping a whole power supply. Work the ladder above, cross-reference the exact code in the ASIC Fault Finder, and check the matching miner profile for model-specific notes.

But once the light points at hardware — a solid red that survives a cold boot, a hashboard that won’t enumerate, a controller stuck in a boot loop, an over-temp that returns under load, or any acrid smell — that is bench territory. D-Central diagnoses and repairs these in-house at our Laval facility: hashboard chip-level rework, control-board and PSU repair, eMMC/NAND recovery, and full-chain bring-up on the same equipment we’ve used since 2016. If the LED has told you which subsystem failed but the fix is a soldering iron and a known-good reference unit, send it to D-Central ASIC repair rather than buying parts on a guess. The light starts the diagnosis; we finish it.