The Miner Status page is the stock Antminer web interface’s live readout from the mining daemon (bmminer/cgminer). It is the single most useful diagnostic screen on the miner: every hashboard, fan, pool connection, and fault reports here in real time. This guide decodes each field, tells you what a healthy value looks like, and shows you how to read the page as a fault-finding tool. The layout below is stock Bitmain firmware; cgminer-derived firmwares expose the same counters under similar names.
The “Summary” Section
The miner’s report card — aggregate performance across all three hashboards.
- Elapsed: Uptime since the mining process last started; it resets on every reboot or firmware restart, not just a power cycle. A stock Antminer needs roughly 15–20 minutes to settle before the hashrate is trustworthy — frequency and voltage are derived at runtime, so early numbers are transient.
- GH/S (RT): Real-time hashrate, sampled over a short window. It naturally jitters second-to-second; that variance is normal.
- GH/S (avg): The average over the whole Elapsed period. This is the number that should match your model’s rated spec. Persistent avg well below rated hashrate points to dead chips, thermal throttling, or an unstable overclock.
- FoundBlocks: Blocks your worker helped solve. On a pooled miner this is almost always
0and has no earnings meaning — you are paid on shares, not blocks. - LocalWork: Work units queued from the pool. It should tick over constantly; a frozen LocalWork counter means the miner has stopped receiving jobs.
- Utility: Accepted shares submitted per minute.
- WU: Work Utility — smoothed accepted difficulty per minute. WU is a more honest indicator of effective throughput than raw RT hashrate because it reflects what the pool actually credits. If RT looks fine but WU is low, you are bleeding output to hardware errors or rejects.
- BestShare: The highest-difficulty share ever found — a lifetime “best luck” trophy with no bearing on earnings. Ignore it for troubleshooting.
The “Pools” Section
The network side: where the miner sends work and how the pool treats it. Most configs list a primary plus one or two backups.
- URL: The pool’s stratum server address and port.
- User: Your worker name (typically
account.worker). - Status: Alive means the miner has a live connection; Dead means it cannot reach that server. As long as one listed pool is Alive, hashing continues. If every pool reads Dead, the miner keeps its boards powered but idles on work — check DNS, the gateway, and that the stratum port is not blocked before assuming a hardware fault.
- Diff: The share difficulty the pool assigned this worker (vardiff). It rises with your hashrate — normal pool tuning, not a problem.
- Accepted (DiffA#): Valid shares the pool credited — should climb steadily.
- Rejected (DiffR#): Shares the pool refused. A trickle is normal; a rising reject ratio usually means an unstable overclock, high latency, or a flaky pool endpoint.
- Stale (DiffS#): Shares submitted for a block the network had already moved past — almost always a latency/ping symptom.
- Discarded: Work dropped because a new block arrived before submission. Normal churn, not an error.
- LSDiff / LSTime: Last-share difficulty and time since the last accepted share. LSTime is a key liveness signal — if it climbs from seconds into minutes, the miner has effectively stopped producing valid work even if it still shows a hashrate.
The “ANTMINER” Section (Per-Hashboard Detail)
This is where you diagnose hardware. Each row is one hashboard (Chain) — the first place a failing board shows itself.
- Chain#: The hashboard’s index. A stock miner has three hashboards, usually numbered Chain 0/1/2 (some firmware labels them 6/7/8). A chain missing from the list entirely is a dead or undetected board — a cable, power, or board fault.
- ASIC#: The count of chips the control board enumerated on that hashboard. This is your most direct chip-health number. It should equal the board’s rated chip count — for example an S9 board carries 63 chips, an S19 board 76, an S19 Pro board 114, an S21 board 108. If ASIC# reads lower than rated, chips have dropped offline — and because chips share voltage domains, a single failure usually knocks out a whole group at once.
- Frequency: The board clock in MHz. Firmware auto-reducing frequency below your model’s normal value means the miner is throttling — almost always heat, or an autotuner backing off an unstable domain.
- GH/s (ideal): Expected hashrate for the board at its current frequency and full chip count.
- GH/s (RT): The board’s actual measured hashrate. Compare RT against ideal per chain: one chain well under its ideal while the others match is the classic signature of failed chips on that board.
- HW: Hardware error count — nonces that failed validation. A small, slowly growing count is normal; what matters is the rate, not the total. HW climbing fast relative to accepted shares indicates failing chips, marginal cooling, or an under-volted domain. Watch the trend.
- Temp chip: On-die junction temperature. Runs hotter than the PCB reading and is what the firmware’s overheat protection watches.
- Temp PCB: Board surface temperature. Sustained PCB temps into the 80s°C — or chip temps near the firmware’s protection limit — trigger throttling or a protective shutdown. Rising temps across the board point to airflow: clogged heatsinks, dust, or a failing fan. (Air-cooled units only — hydro and immersion miners are fanless and liquid-cooled, so do not apply air-cooling logic to them.)
- ASIC status: A per-chip map of the chain, typically a string of
ocharacters — one per ASIC — where anxmarks a chip that failed to enumerate. The position of thexlocalizes the dead domain. (Some firmware shows0for OK,Xfor failed.) - Fan: Fan speed in RPM. A stock air-cooled S-series runs two intake and two exhaust fans; a
0reading means lost tach feedback and the firmware will usually halt on fan-protection. All fans pinned to maximum means the board is fighting heat.
Reading the Page as a Fault-Finder
Put the fields together and work top to bottom:
- Is it alive? Check Pools Status (at least one Alive) and LSTime (seconds, not minutes). If the network side is dead, fix that first — the boards are fine, just starved of work.
- Is it hashing to spec? Compare GH/S (avg) to your model’s rating; a shortfall sends you to the per-chain table.
- Which board is bad? Find the chain whose ASIC# is short, whose RT trails ideal, or whose status string carries an
x. - Why is it bad? Cross-check temps and fans. High temps plus reduced frequency is a cooling problem you can often fix in place; a short ASIC# with normal temps is a chip/domain fault that needs the board on a bench.
Common misreads to avoid: Discarded and Stale shares are normal churn, not damage. A non-zero HW count is not a fault by itself — only a fast-climbing one is. BestShare and FoundBlocks are trivia, not health metrics.
Related
When the status page points at a failing board, take it further with the ASIC fault-finder to isolate the defect, source hashboards, fans and sensors from ASIC repair parts, or hand the unit to a bench tech through start a repair.
