Worker Stats — Fix Low Hashrate & Rejects
Diagnose your solo mining worker stats: what every metric means, then how to find and fix low hashrate, rejected shares and repeated disconnects.
Your worker stats page is the most important screen in solo mining: it shows whether your hashrate is reaching the pool, whether shares are being accepted, whether your miner is healthy, and how close you have come to a block. Reading it correctly — and acting on what it says — is the difference between mining around the clock with good odds and quietly losing capacity for weeks. This guide explains every metric, then fixes the problems that actually cost money, organized by symptom.
Key Takeaways
- Displayed hashrate is estimated from your share rate. If shares stop reaching the pool for any reason, your hashrate drops on the dashboard even when the ASIC is hashing fine locally.
- A reject rate under 0.5% is healthy; above 2% wastes real electricity. A rejected share burns the same power as an accepted one — it is paid-for work the pool refuses to credit.
- Most reject and disconnect problems are latency. The single easiest fix is a wired Ethernet connection plus the closest SoloFury region.
- The reject label tells you where to look: stale points to latency, “low difficulty” to vardiff, duplicate to firmware/worker names, hardware error to failing chips.
- A low best share is normal. It is a maximum-ever statistic; your real odds depend on cumulative hashrate over time, not on best share.
Where do you find your worker stats?
SoloFury exposes worker stats in three places, each with a different strength.
The live miner dashboard at /miner/?addr=<your_wallet>&coin=<bch|btc|bc2|bch2|xec> is the fastest way to see every worker attached to your wallet on a given coin. It refreshes roughly every 30 seconds and shows hashrate, share counts, best share, and worker health.
The per-worker detail view — click any worker name on the dashboard — adds history, a hashrate graph, and individual stats over time.
The Telegram bot (@SoloFuryBot) sends proactive notifications: subscribe to your wallet and it messages you when a worker goes offline, when shares stop arriving, and when you find a block.
What does each metric mean?
Hashrate (1m, 5m, 1h)
Three hashrate averages appear on the dashboard, each smoothing over a different window.
| Label | Meaning | Character |
|---|---|---|
| 1m | Average over the last minute | Real-time but noisy |
| 5m | Average over the last 5 minutes | Stable — best for “is it working now” |
| 1h | Average over the last hour | Smooth — best for trend |
For solo mining the 5m hashrate is the most useful single number: the 1m is too noisy because variance is large over short windows, and the 1h is too slow to reveal a sudden fault.
Accepted shares
Every valid share counts, and the number going up is the most basic “things are working” signal. A worker showing zero accepted shares for more than 10 minutes is broken from the pool’s point of view, regardless of what its local interface claims.
Rejected shares and reject rate
Rejected shares are submissions the pool refused — because the share was a duplicate, its difficulty was below the current vardiff target, the job had expired, or the share data contained a hardware error. Crucially, your ASIC spent the same electricity computing a rejected share as an accepted one, so rejects are paid-for work that earns nothing.
A reject rate under 0.5% is healthy, 0.5–2% is acceptable but worth investigating, and above 2% needs attention now. Above 3% you are bleeding money. These thresholds match the broader industry consensus across major pools and firmware.
Stale shares
Stale shares are a specific reject: your miner submitted work based on a block template the pool had already replaced. A high stale rate means your miner is receiving new work too slowly — almost always a latency problem. Keep stale under 1%; above 2% means you should switch to a closer SoloFury region or move the miner to wired Ethernet.
Best share
Best share is the highest-difficulty share you have ever submitted, expressed against network difficulty. A best share of 0.5 means you once submitted a share at 50% of network difficulty — a near miss. In solo lottery mining every share is an attempt at a block, and best share is simply the closest you have come. It is a fun luck tracker, but it does not change your future odds.
Last seen
This is when the pool last received a share from the worker. Under 5 minutes is healthy, over 15 minutes is concerning, and over an hour means the worker is effectively dead and needs investigation.
Ping (latency to the pool)
Ping is the round-trip time from your miner to the stratum server. Under 50 ms is excellent, 50–150 ms is good, 150–300 ms is workable but suboptimal, and above 300 ms means you should switch to a closer region. High ping directly causes stale shares, making it the single biggest source of fixable revenue loss.
Why is my hashrate lower than expected?
If your S21+ should show 235 TH/s but the dashboard shows 180 TH/s, triage in this order — the first question splits the problem in half.
Step 1 — Does the local ASIC interface show the same number?
Log into the miner’s own web interface and read its hashrate. If the ASIC also shows 180 TH/s, the problem is physical (chip failure, thermal throttling, over-aggressive undervolting, or a power issue). If the ASIC shows 235 TH/s locally but only 180 TH/s reaches SoloFury, the problem is network or stratum.
Step 2 — Physical causes (the ASIC itself reads low)
| Cause | Diagnostic | Fix |
|---|---|---|
| Hashboard failure | One or more chips at 0 GH/s, or a chain failing | Replace the hashboard; use warranty if covered |
| Thermal throttling | Temperature above 85°C, fans pinned at 100% | Improve ventilation, lower ambient temperature |
| Over-aggressive undervolt | Custom firmware lost hashrate after a tuning change | Raise voltage back toward stock |
| Power supply limited | PSU at full capacity, voltage sags under load | Upgrade the PSU, check 220V wiring gauge |
| Firmware regression | Issue began right after a firmware update | Roll back to the previous stable firmware |
Step 3 — Network/stratum causes (the ASIC reads fine, the pool reads low)
| Cause | Diagnostic | Fix |
|---|---|---|
| Stratum disconnects | Worker shows repeated reconnects in its log | See “Why does my worker keep disconnecting?” |
| High reject rate | Reject rate above 2% in pool stats | See “Why is my reject rate high?” |
| High stale rate | Stale rate above 2% | Switch to the closest SoloFury region; use Ethernet |
| Vardiff not settled | New worker, dashboard hashrate still climbing | Wait 30 minutes for vardiff to converge |
Why is my reject rate high?
A reject rate above 2% means real hashrate is being wasted. The reject label in your ASIC log tells you which of four problems you have.
”Job not found” or “stale” rejects
Your miner is submitting work that has already expired — almost always latency or packet loss. Fix it by, in order: switching to your closest region (bch.solofury.com for Atlanta, eu-bch.solofury.com for Frankfurt, asia-bch.solofury.com for Singapore; substitute your coin); moving the miner to wired Ethernet instead of Wi-Fi, which is the single easiest stale-share fix; checking ping (above 150 ms, switch region); checking ISP packet loss with mtr or traceroute (above 1% causes stales); and verifying the miner’s clock is NTP-synced, since a clock several seconds out can trigger stale rejects on some firmware.
”Low difficulty” rejects
Your miner submitted shares below the current vardiff target, usually a temporary glitch right after a hashrate change. Wait 30 minutes for vardiff to re-stabilize. If it persists, make sure no other machine is reusing the same worker name with a different hashrate (which confuses vardiff), or restart the ASIC to force a fresh handshake.
”Duplicate” rejects
The same share was submitted twice — typically a firmware bug or two machines sharing one worker name. Give every worker a unique name (wallet.workerA, wallet.workerB, never the same) and update to the latest stable firmware.
”Hardware error” rejects
Your chips are computing invalid shares, which points to failing or unstable silicon. Inspect chip temperatures for hot or cold outliers, ease off any undervolt, and replace the affected hashboard if the errors persist.
Why does my worker keep disconnecting?
A worker that keeps dropping and reconnecting loses a few seconds of hashing each cycle. The causes are almost always on the network side.
| Cause | Diagnostic | Fix |
|---|---|---|
| Flaky ISP / packet loss | mtr shows over 0.5% loss | Connect to the closest SoloFury region; use Ethernet |
| Pool restart | Many workers drop at once across the pool | Wait — automatic reconnect recovers within seconds |
| Firewall / NAT timeout | Disconnect every ~5 minutes precisely | Raise the router’s TCP keepalive, or rely on the miner’s reconnect loop |
| Bad cable or PoE injector | Random drops, sometimes with power cycles | Replace the cable, check PoE health |
| IP conflict | DHCP handed the same IP to two devices | Reserve static IPs per ASIC in the router |
| ISP shaping / DPI | Drops cluster at peak hours | Try a different stratum port or a VPN tunnel |
How SoloFury’s regional endpoints help
SoloFury’s regional endpoints (eu-*.solofury.com and asia-*.solofury.com) are built to hold long-lived stratum connections and to absorb brief network interruptions, so they keep your worker attached through short ISP blips and pool-side restarts that might otherwise drop you. If you are not in North America, prefer the regional endpoint closest to you over the Atlanta primary. For an encrypted connection on top of that, see the TLS Stratum Mining guide.
Why are no shares arriving at all?
If a worker shows “Last seen: never” or hours ago, it is completely offline from the pool’s view. Work through this sequence.
- Can you reach the ASIC’s local interface on its IP? No → power, network, or hardware. Yes → continue.
- Does the local interface show it as mining? No → check the pool config, restart, check firmware. Yes → continue.
- What pool URL is configured? It must be
bch.solofury.com:7070,btc.solofury.com:6060,bc2.solofury.com:8080,bch2.solofury.com:8585, orxec.solofury.com:9090(or the matchingeu-/asia-regional hostname). - What is the worker username? It must be
<wallet>.<worker_name>, with the wallet valid for that coin. - Can the miner reach the pool? Use the ASIC’s diagnostics, or ping/telnet from another machine on the same subnet.
The most common root cause: wrong wallet format
Each coin needs its wallet in the correct format, and a wrong format is the most frequent reason a worker never appears.
| Coin | Format | Example |
|---|---|---|
| BTC | Bech32 or legacy | bc1q... or 1... |
| BCH | CashAddr with prefix (or legacy) | bitcoincash:qq... or 1... |
| BC2 | Bech32 or legacy | bc1q... or 1... |
| BCH2 | CashAddr with the bitcoincashii: prefix | bitcoincashii:qq... |
| XEC | eCash with prefix | ecash:qq... |
Why is my best share stuck low?
If your best share is something like 0.001 of network difficulty after weeks of mining, it does not mean you are unlucky or that your odds are bad. Best share is a maximum-ever statistic: in a random process the maximum creeps upward slowly and erratically, so a low value over weeks is statistically normal — not a fault.
What actually drives block-finding probability is cumulative hashrate over time, not best share. If your hashrate is solid and your reject rate is low, you are buying lottery tickets correctly, and variance simply takes time to express. For the math behind solo-mining variance and what to expect at different hashrate levels, see Solo Mining Lottery Math and the Solo Probability Calculator.
Quick reference: symptom to most likely cause
| Symptom | First thing to check | Most common cause |
|---|---|---|
| Hashrate 20%+ below spec (steady) | ASIC local interface | Hashboard or thermal issue |
| Hashrate swings minute to minute | Normal for small workers | Variance — read the 1h average |
| Reject rate above 2% | Ping and reject label | Latency — switch region, use Ethernet |
| Stale rate above 2% | Ping and connection type | Latency — switch region, use Ethernet |
| Worker offline (“hours ago”) | ASIC power and network | Power loss or wrong stratum config |
| Frequent disconnects | Router/NAT, ISP | Use the closest regional endpoint |
| Best share very low after weeks | This is statistical | Normal — keep mining |
| Hashrate climbing slowly after start | Vardiff converging | Wait 30 minutes |
How do you choose the right region?
Latency is the most controllable factor for share quality, so connect to the region closest to your miner. SoloFury operates three stratum regions.
| Region | Endpoint pattern | Best for |
|---|---|---|
| Atlanta (primary) | <coin>.solofury.com | North America, Caribbean, eastern South America |
| Frankfurt (EU) | eu-<coin>.solofury.com | Europe, Middle East, Africa |
| Singapore (Asia) | asia-<coin>.solofury.com | Asia, Oceania, India |
Test latency by pinging each endpoint from your network and picking the lowest. If two are close, prefer the one with lower jitter (variance in ping), not just the lower average — jitter, not raw latency, is what drives stale shares.
When should you contact support?
If, after working through this guide, your worker still shows one of these, reach out:
- Multiple workers dropping at the same instant on SoloFury only (not on other pools).
- All workers showing zero shares while the ASIC interface confirms hashing.
- A block listed in the Hall of Fame but the reward never reached your wallet.
Contact SoloFury via the Telegram bot or @SoloFuryPool on X, and include your wallet address, the coin, the worker name with the symptom, and the endpoint URL configured in the ASIC. Most issues resolve quickly once support can look up the worker history.
Next Steps
- Run the Miner Health Check guide for a full diagnostic walkthrough of a misbehaving ASIC.
- Setting up a new miner? See the Antminer S21+ guide, the Antminer S19 & Whatsminer guide, or the Bitaxe guide.
- For rental-hashrate differences, see the NiceHash Solo Mining guide.
- For the math of share difficulty and variance, read the Solo Mining Variance article.
- For live pool health, check the System Status page.
Frequently Asked Questions
What is a normal reject rate for solo mining?
Under 0.5% is healthy, 0.5–2% is acceptable but worth a look, and above 2% needs attention. Above 3% you are wasting meaningful electricity. A rejected share consumes the same power as an accepted one, so the reject rate maps directly to wasted money.
Why does my dashboard hashrate look lower than my ASIC's?
The dashboard estimates hashrate from your share submission rate, not from the ASIC directly. If shares are delayed or dropped on the way to the pool, the displayed hashrate falls even though the ASIC is hashing fine. A gap between the two readings points to a network or stratum problem.
What causes stale shares and how do I reduce them?
Stale shares come from latency — your miner submits work after the pool moved to a new block template. Reduce them by using wired Ethernet instead of Wi-Fi and connecting to the closest SoloFury region. Keep stale under 1%.
Is a low best share a bad sign?
No. Best share is a maximum-ever statistic that grows slowly and erratically, so a low value after weeks is normal. Your odds depend on cumulative hashrate over time, not on best share.
My worker disconnects every five minutes — what is it?
A precise five-minute cycle usually means a firewall or NAT timeout closing an idle connection. Raise your router's TCP keepalive interval, or rely on the miner's own reconnect loop. Connecting to the closest regional endpoint also helps hold the session.
Why doesn't my worker appear on the dashboard at all?
The most common cause is a wallet in the wrong format. BCH/BCH2 need their CashAddr prefix (bitcoincash: / bitcoincashii:), XEC needs ecash:. Also confirm the pool hostname, the port for the coin, and that the ASIC can reach the network.
How long should I wait before trusting my hashrate reading?
At least two hours. Vardiff converges over the first 15–30 minutes, and short-window averages are noisy, so the 1h average after a couple of hours is the reliable figure.
Does switching region change my chances of finding a block?
No. Region affects latency and therefore stale shares, not block probability. Picking the closest region simply means more of your hashrate counts as accepted work.