Reading Miner Logs: What the Error Codes Actually Mean

If the dashboard is your miner’s speedometer, the system log is the black box flight recorder. It captures every event, error, warning, and decision the miner makes, timestamped and stored for your review. When something goes wrong — and eventually something always does — the log is where you go to figure out what happened.

The problem? Miner logs look like cryptic walls of text written in a language only machines understand. In this guide, we’ll teach you how to read that language.

Where to Find the Logs

The location depends on your miner brand and firmware.

Antminer

On Antminers running stock firmware:

• Web Interface: Navigate to “System” -> “Log” or “Kernel Log”
• The page displays a live-scrolling text log from the CGMiner or BMMiner process
• Some models also have a separate “System Log” for boot messages and OS-level events
• You can usually click a “Download” button to save the full log as a text file

On Antminers running Braiins OS+:

• Navigate to “System” -> “Logs” or use the built-in log viewer
• Braiins provides cleaner, more structured logs with severity levels
• SSH access also lets you read logs directly via the command line: cat /tmp/bosminer.log

Whatsminer

On Whatsminers:

• Web Interface: Navigate to “Log” or “System Log” in the main menu
• Whatsminer logs tend to be more compact than Antminer logs
• Some Whatsminer models require you to click “Download Log” to get the full system log as a compressed file
• The web interface may only show recent entries; the downloaded file contains the complete history since last boot

Tip

Get in the habit of downloading and saving your logs before rebooting or factory resetting your miner. A reboot wipes the in-memory log on most models. If you’re troubleshooting a recurring problem, having logs from multiple sessions lets you spot patterns.

Anatomy of a Log Entry

Every log entry typically has the same basic structure:

[2024-03-15 14:32:07] [notice] chain 2: found 63 chips
[2024-03-15 14:32:08] [error] chain 1: chip 42 not responding
[2024-03-15 14:32:09] [warning] fan 3: RPM below threshold (1200 < 2000)

Let’s break that apart:

• Timestamp (2024-03-15 14:32:07) — When the event occurred. Critical for correlating issues with environmental changes (did the room get hot at 2 PM? Did power flicker at midnight?).
• Severity level (notice, error, warning) — How serious the event is.
• Component (chain 2, fan 3, etc.) — Which part of the miner generated the message.
• Message — What actually happened.

Severity Levels

Level	What It Means	Should You Worry?
debug	Extremely detailed info for developers	No — usually filtered out
info / notice	Normal operational events	No — this is the miner narrating its life
warning	Something suboptimal but not yet broken	Maybe — monitor the situation
error	Something failed	Yes — investigate promptly
critical / fatal	Something failed badly enough to stop mining	Yes — immediate attention needed

Common Error Codes and What They Mean

Here’s the part you came for. Let’s decode the most frequent errors you’ll encounter in miner logs.

Chip Failures

These are the most common and most concerning errors in ASIC mining.

“ASIC chip X dead” / “chip X not responding” / “chain Y: missing chip Z”

[error] chain 0: chip 28 not responding after 3 attempts
[error] chain 2: ASIC #14 failure detected

This means a specific chip on a hash board has stopped working. Each hash board contains dozens of ASIC chips (typically 60-120+ depending on the model). When one dies, that board’s hashrate drops proportionally.

What to do:

• One or two dead chips is usually acceptable — the miner keeps running with slightly reduced hashrate on that board
• If the count keeps growing (more chips dying over days/weeks), the board is degrading and may need repair or replacement
• A sudden jump from 0 dead chips to 10+ suggests a power delivery issue on the board or a thermal event

Note

Dead chips are usually permanent. Unlike software issues, a dead ASIC chip is physically damaged (electromigration, solder joint failure, or silicon degradation). Rebooting won’t bring it back. Professional board repair services can sometimes replace individual chips, but it requires specialized equipment.

“chain X: found Y chips (expected Z)”

[warning] chain 1: found 57 chips (expected 63)

During startup, the miner enumerates all chips on each board. If it finds fewer than expected, some chips are unresponsive. The missing chips (63 - 57 = 6 in this example) are effectively dead. The miner will continue operating with reduced hashrate on that chain.

Temperature Errors

“temperature too high” / “PCB temp over limit” / “chip temperature exceeds threshold”

[warning] chain 0: chip temp 87C exceeds warning threshold (85C)
[error] chain 0: chip temp 95C exceeds critical threshold (90C) -- throttling
[critical] system: emergency shutdown due to temperature 98C

Temperature errors follow a progression:

1. Warning — Temperature is high but still within limits. The miner keeps running normally but you should act.
2. Throttling — Temperature exceeded the safe limit. The miner automatically reduces chip frequency to generate less heat. Hashrate drops but the hardware is protected.
3. Shutdown — Temperature is dangerously high. The miner stops all hashing to prevent permanent damage.

What to do:

• Check ambient room temperature — is it abnormally hot?
• Inspect air intake and exhaust for dust buildup or obstructions
• Verify all fans are spinning at normal RPM
• Check that the miner has adequate spacing from walls and other miners
• If one board is significantly hotter than others, suspect a thermal paste issue or a dead fan on that side

Fan Failures

“fan X: speed below minimum” / “fan abnormal” / “fan lost”

[error] fan 2: RPM 0 (minimum: 2000) -- fan failure detected
[warning] fan 0: speed unstable (3200, 0, 3100, 0, 3150)

When a fan fails or drops below its minimum RPM threshold, the miner logs an error. The zeroes alternating with normal readings in the second example suggest a fan with a failing bearing — it spins briefly, stops, spins again.

What to do:

• Physically inspect the fan. Is it spinning? Is it making grinding noises?
• Check the fan connector on the control board — it might have come loose
• Replace the fan promptly. Miners can overheat within minutes without adequate cooling
• If the fan reads 0 RPM but is visually spinning, the fan’s tachometer sensor might be broken — less urgent but still worth replacing

Caution

Some miners will refuse to start hashing if a fan is detected as failed. This is a safety feature, not a bug. Don’t try to bypass fan detection — it’s there to prevent your miner from becoming a very expensive space heater and then a very expensive paperweight.

Network and Pool Errors

“Stratum connection failed” / “pool connection timeout”

[error] pool 0: stratum connection to stratum+tcp://pool.example.com:3333 failed
[warning] pool 0: connection timeout after 30s, retrying...
[notice] switching to backup pool 1

These mean the miner cannot reach the mining pool. Possible causes:

• Internet connection down — Check your router and modem
• Pool server down — Visit the pool’s status page or social media
• DNS resolution failure — Try using the pool’s IP address instead of hostname
• Firewall blocking port — Mining typically uses port 3333, 3334, or 25 — make sure these aren’t blocked
• Wrong pool URL — Double-check for typos in the stratum address

“stratum: authentication failed”

[error] pool 0: authorization failed for worker account.rig01

The pool rejected your worker credentials. Check:

• Is the worker name spelled correctly?
• For wallet-based pools: is the Bitcoin address valid and correctly formatted?
• For account-based pools: does the account exist?
• Did you recently change your pool account password?

Share Submission Errors

“accepted” and “rejected” in logs

[notice] pool 0: accepted share 47f2a... (diff: 512, target: 1024)
[warning] pool 0: rejected share 8a3c1... reason: stale
[warning] pool 0: rejected share d9e7b... reason: duplicate
[warning] pool 0: rejected share 1b4f0... reason: low difficulty

Your miner constantly submits shares to the pool. Most should be accepted. Rejected shares are wasted work. Here’s what each rejection reason means:

Rejection Reason	What Happened	Is It a Problem?
stale	A new block was found before your share arrived	Normal in small amounts (1-3%). High stale rate means slow internet or distant pool server
duplicate	You submitted the same share twice	Usually a firmware bug or proxy issue
low difficulty	The share doesn’t meet the pool’s minimum difficulty	Likely a difficulty mismatch; usually resolves after reconnection
job not found	The share references a job the pool no longer has	Similar to stale — the job expired before the share arrived
unauthorized	The worker isn’t authenticated	Check your pool credentials

Tip

A rejection rate below 1-2% is normal and nothing to worry about. If rejections climb above 3-5%, investigate. Stale shares increase with network latency — if your miner is in Australia connecting to a pool server in Europe, you’ll see more stales. Choose a pool with servers geographically close to you.

Hardware Errors (HW Errors)

“HW error” / “hardware error rate”

[warning] chain 1: HW errors: 47 (rate: 0.03%)
[error] chain 2: HW error rate 2.1% exceeds threshold

Hardware errors occur when an ASIC chip produces an incorrect hash result. A small number is normal — silicon isn’t perfect, and at billions of hashes per second, occasional errors are expected. The error rate matters more than the absolute count.

HW Error Rate	Status	Action
Below 0.1%	Normal	No action needed
0.1% - 0.5%	Slightly elevated	Monitor; check temperatures
0.5% - 2%	Concerning	Reduce overclock or check board health
Above 2%	Problematic	Lower frequency; board may need repair

High HW error rates usually mean chips are being driven too hard (overclock too aggressive), running too hot, or physically degrading.

Reading Startup Logs

The startup sequence is particularly informative. Here’s a condensed example of what a healthy Antminer boot looks like:

[notice] system: booting... firmware version 2024.03.1
[notice] network: DHCP lease obtained, IP 192.168.1.105
[notice] chain 0: initializing...
[notice] chain 0: found 63/63 chips
[notice] chain 1: initializing...
[notice] chain 1: found 63/63 chips
[notice] chain 2: initializing...
[notice] chain 2: found 63/63 chips
[notice] fans: all 4 fans detected and running
[notice] pool 0: connecting to stratum+tcp://pool.example.com:3333
[notice] pool 0: authorized worker account.rig01
[notice] mining: starting at frequency 500MHz, voltage 12.8V
[notice] mining: hashrate ramping up...
[notice] mining: target hashrate reached (198 TH/s)

Compare that to a problematic boot:

[notice] system: booting... firmware version 2024.03.1
[notice] network: DHCP lease obtained, IP 192.168.1.105
[notice] chain 0: initializing...
[notice] chain 0: found 63/63 chips
[notice] chain 1: initializing...
[error] chain 1: found 0/63 chips -- board not detected
[notice] chain 2: initializing...
[notice] chain 2: found 58/63 chips
[warning] chain 2: 5 chips not responding
[error] fan 3: not detected
[notice] pool 0: connecting to stratum+tcp://pool.example.com:3333
[notice] pool 0: authorized worker account.rig01
[notice] mining: starting at frequency 500MHz (reduced due to errors)

In the problematic boot, you can immediately see: Board 1 is completely undetected (bad connection, dead board, or bad cable), Board 2 has 5 dead chips, and Fan 3 is missing. The miner started anyway with reduced performance, but these issues need attention.

How to Export and Save Logs

Logs are stored in memory on most miners, which means they disappear on reboot. To preserve them:

Antminer

1. Go to “System” -> “Log” in the web interface
2. Click “Download Log” (if available) to save as a text file
3. Alternatively, use SSH: ssh root@MINER_IP then cat /tmp/log/miner.log > /tmp/saved_log.txt
4. Copy the file off the miner using SCP or SFTP

Whatsminer

1. Go to the “Log” page in the web interface
2. Click “Download Log” — this usually generates a compressed archive
3. The archive contains multiple log files: system log, miner log, and sometimes crash dumps
4. Some Whatsminer models support log export via the API using tools like whatsminer-api

Tip

For large mining operations, consider setting up a centralized log collection system. Tools like Foreman or custom scripts can pull logs from all your miners periodically and store them in a searchable database. When you have 100+ machines, manually checking each one’s log page is not practical.

Log Analysis Tips

Pattern Recognition

The most useful skill in log analysis is spotting patterns:

• Same error repeating at regular intervals — Usually points to a systematic issue. For example, “stratum connection timeout” every 60 seconds suggests a network problem, not a pool problem.
• Errors that correlate with time of day — Temperature errors that appear every afternoon and disappear at night point to ambient temperature changes. Common in hot climates or poorly ventilated rooms.
• Escalating errors — A chip count that drops from 63 to 62 to 60 to 55 over weeks indicates a board that’s slowly dying. Plan for replacement.
• Errors that appear after a change — Did you update firmware yesterday and start seeing errors today? Did you change the overclock settings? Changes are the usual suspects.

What to Include in a Support Request

If you need to contact the manufacturer or a repair service, a good log excerpt saves everyone time. Include:

1. The full startup sequence from the most recent boot
2. Any error messages with their timestamps
3. The firmware version and miner model
4. What you were doing when the problem started (changed settings? Power outage? Nothing?)
5. The ambient temperature and cooling setup

Don’t just say “my miner isn’t working.” Send the log. The log is the truth — it tells the story of exactly what happened, in what order, without guessing.

Quick Reference: Error Cheat Sheet

Error Pattern	Likely Cause	First Steps
chip X not responding	Dead ASIC chip	Monitor count; replace board if growing
found Y/Z chips (Y < Z)	Dead or undetected chips	Check cables; reseat boards
temp exceeds threshold	Overheating	Check fans, airflow, ambient temp
fan X: RPM 0	Fan failure	Replace fan immediately
stratum connection failed	Network issue	Check internet, pool URL, firewall
authorization failed	Bad credentials	Verify worker name and pool account
rejected: stale	Share arrived too late	Normal in small amounts; check latency
HW error rate high	Chips driven too hard	Lower frequency or check cooling
chain X: not detected	Board connection issue	Check ribbon cables and power connectors
watchdog: restarting	Miner auto-recovery	Check what caused the initial failure

Wrapping Up

Reading miner logs is not glamorous, but it’s one of the most practical skills you can develop as a miner. The dashboard gives you a quick health check, but the logs give you the full story — exactly what went wrong, when, and often why.

The key lessons: check logs after any unexpected behavior, save them before reboots, look for patterns over time, and don’t ignore escalating errors. A chip failure today is a board failure next month if you’re not paying attention.

In the next article, we’ll compare the Antminer and Whatsminer web interfaces side by side — showing you where each brand puts the same settings, so switching between brands doesn’t leave you lost.