Reading Your Worker Stats — Diagnosing Low Hashrate, High Reject Rate, and Stratum Disconnects
Complete diagnostic guide for SoloFury worker statistics. Learn what every number means, how to identify the root cause of low hashrate, high reject rates, stale shares, and disconnections, and how to fix them.
Your worker stats page is the most important screen in solo mining. It tells you whether your hashrate is reaching the pool, whether shares are being accepted, whether your miner is healthy, and how close you are to finding a block. Reading it correctly — and acting on what it says — is the difference between mining 24/7 with good odds and quietly losing capacity for weeks without noticing.
This guide walks through every metric on the SoloFury miner stats page, what each number should look like, what to do when something is off, and how to triage problems by symptom.
1. Where to Find Your Worker Stats
SoloFury exposes worker stats in three places, each with different strengths:
Live miner dashboard at /miner/?addr=<your_wallet>&coin=<bch|btc|bc2|bch2|xec>
The fastest way to see all workers attached to your wallet on a specific coin. Updates every ~24 seconds. Shows hashrate, share counts, best share, and worker health.
Per-worker detail — click any worker name on the dashboard to see history, hashrate graph, and individual stats over time.
Telegram bot (@SoloFuryBot) — subscribe to your wallet for proactive notifications. Receives messages when workers go offline, when shares stop arriving, and when you find a block.
2. The Core Metrics — What Each Number Means
Hashrate
Three hashrate values appear on the dashboard:
| Label | Meaning | Typical lag |
|---|---|---|
| 1m | Average hashrate over last 1 minute | Real-time but noisy |
| 5m | Average hashrate over last 5 minutes | Stable, best for “is it working right now” |
| 1h | Average hashrate over last 1 hour | Smooth, best for long-term trend |
For solo mining, the 5m hashrate is the most useful single number. The 1m is too noisy (variance is huge over short windows), and the 1h takes too long to reflect a fault.
Accepted Shares
Every valid share your miner submits is counted. 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 perspective, regardless of what its local UI says.
Rejected Shares (and Reject Rate %)
Rejected shares are submissions the pool refused for one of several reasons:
- Share was already submitted by another miner (“duplicate”)
- Share difficulty too low for current vardiff target
- Stratum job expired before the share arrived
- Hardware error in the share data
Healthy reject rate: under 0.5%. Acceptable: 0.5–2%. Problematic: above 2%. A 5%+ reject rate is wasting real hashrate and needs investigation immediately.
Stale Shares
Stales are a special form of rejected share where your miner submitted work that was based on a block that has already been mined (the pool has moved on to a new block template). High stale rate means your miner is receiving new work too slowly — almost always a network latency problem.
Healthy stale rate: under 1%. Above 2% means you should switch to a closer SoloFury region.
Best Share
The highest-difficulty share you have ever submitted, divided by network difficulty. This is a vanity metric and a near-miss indicator: a “best share” of 0.5 means you submitted a share that was at 50% of network difficulty — close to a real block.
In solo lottery mining, every share is trying to be a block. The best share number is just the closest you’ve gotten so far. A high best share doesn’t change your future odds, but it’s a fun way to track your luck.
Last Seen
When the pool last received a share from this worker. Healthy: under 5 minutes. Concerning: over 15 minutes. Dead: over 1 hour. If a worker shows “Last seen: 6h ago” you have a problem to investigate.
Ping (Latency to Pool)
Round-trip time from your ASIC to the pool’s stratum server. Under 50ms: excellent. 50–150ms: good. 150–300ms: workable but suboptimal. Above 300ms: switch to a closer region.
High ping directly causes stale shares (your miner gets new work too late). It’s the single biggest cause of fixable revenue loss.
3. Symptom: Low Hashrate (Displayed Below Expected)
If your S21+ should show 235 TH/s but the SoloFury dashboard shows 180 TH/s, something is wrong. Triage in this order:
Step 1: Is the local ASIC UI showing the same number?
Log into your ASIC’s web interface and check its own hashrate reading. If the ASIC’s own UI also shows 180 TH/s, the problem is physical: chip failure, thermal throttling, undervolting, or power supply 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 (ASIC local UI also shows low)
| Cause | Diagnostic | Fix |
|---|---|---|
| Hashboard failure | ASIC UI shows one or more chips at 0 GH/s or chains failing | Replace hashboard, contact warranty if under coverage |
| Thermal throttling | Temperature above 85°C, fan speed at 100% | Improve ventilation, reduce ambient temp, undervolt |
| Undervolting too aggressive | Custom firmware showing efficiency >18 J/TH but losing hashrate | Increase voltage, return closer to stock |
| Power supply insufficient | PSU at 100% capacity, voltage drops under load | Upgrade PSU, check 220V wiring AWG |
| Firmware bug | Recent firmware update preceded the issue | Roll back firmware to previous stable version |
Step 3: Network/stratum causes (ASIC local UI is fine, pool shows low)
| Cause | Diagnostic | Fix |
|---|---|---|
| Stratum disconnects | Worker shows reconnects in log | See Section 5 on disconnects |
| High reject rate | Reject rate above 2% in pool stats | See Section 4 on rejects |
| High stale rate | Stale rate above 2% | Switch to closer SoloFury region |
| Vardiff not stabilized | New worker, dashboard hashrate climbing slowly | Wait 30 minutes for vardiff to settle |
4. Symptom: High Reject Rate (Above 2%)
A reject rate above 2% means real hashrate is being wasted. Diagnose by what type of rejects you see in your ASIC log.
Type A — “Job not found” or “Stale” rejects
Your ASIC is submitting shares for work that has already expired. Almost always a latency or network problem.
Fixes:
- Switch to your closest SoloFury region:
bch.solofury.com(Atlanta),eu-bch.solofury.com(Frankfurt),asia-bch.solofury.com(Singapore). Substitutebchwith your coin (btc,bc2,bch2,xec). - Check ping: from a machine on the same network as the ASIC,
ping bch.solofury.com. If above 150ms, switch region. - Check ISP packet loss:
mtrortracerouteto the pool. Packet loss above 1% causes stale shares. - Verify NTP/clock sync: a clock more than a few seconds out of sync will cause stale-share rejects on some ASIC firmwares.
Type B — “Low difficulty” rejects
Your miner submitted shares below the pool’s current vardiff target. Usually a temporary glitch when vardiff hasn’t caught up to a hashrate change.
Fixes:
- Wait 30 minutes for vardiff to re-stabilize
- If persistent: check that no other worker is reusing the same worker name with a different hashrate (causing vardiff confusion)
- Restart the ASIC to force a fresh stratum handshake
Type C — “Duplicate” rejects
Same share submitted twice. Usually a firmware bug or two miners sharing a worker name.
Fixes:
- Make sure every worker has a unique name (
wallet.workerA,wallet.workerB, never the same) - Update firmware to latest stable
Type D — “HW error” rejects
Hardware-generated rejects: your ASIC’s chips are computing invalid shares. Indicates failing silicon.
Fixes:
- Inspect chip temperatures (look for hot or cold outliers)
- Reduce undervolting / increase voltage
- Replace affected hashboard if persistent
5. Symptom: Stratum Disconnects (Worker Keeps Reconnecting)
A worker that keeps dropping and reconnecting is wasting a few seconds of hashing each cycle. Causes are usually network-side.
Common causes
| Cause | Diagnostic | Fix |
|---|---|---|
| TCP keepalive fails over flaky ISP | mtr shows >0.5% packet loss | Use HAProxy relay region closer to you (already enabled on SoloFury EU/Asia endpoints) |
| Pool maintenance / restart | Multiple workers disconnect at once across the pool | Wait — automatic reconnect should kick in within seconds |
| Firewall / NAT timeout | Disconnect every ~5 minutes precisely | Configure router for longer TCP keepalive (>10 min), or rely on miner’s own reconnect loop |
| Bad ethernet cable or PoE injector | Random disconnects, possibly correlated with miner power cycles | Replace cable, check PoE health |
| ASIC IP conflict | DHCP returns same IP to two devices | Reserve static IPs in your router for each ASIC |
| ISP DPI / shaping | Disconnects correlate with peak hours | Try a different stratum port or VPN tunnel |
How SoloFury’s HAProxy relays help
SoloFury’s EU and Asia endpoints (eu-*.solofury.com and asia-*.solofury.com) are HAProxy relays with 24-hour TCP timeouts and connection-keepalive enabled. They keep your worker connected during pool-side restarts and ISP blips that would otherwise drop you. Always prefer a regional relay over the Atlanta primary if you are not in North America.
6. Symptom: No Shares At All (Worker Shows “Last Seen: Never” or Hours Ago)
Worker is completely offline from the pool’s view.
Diagnostic sequence
- Can you reach the ASIC’s local UI on its IP? If no → power, network, or ASIC hardware. If yes → continue.
- Does the ASIC’s local UI show it as mining? If no → check pool config in ASIC, restart, check firmware. If yes → continue.
- What pool URL is configured in the ASIC? Must be one of:
bch.solofury.com:7070,btc.solofury.com:7070,bc2.solofury.com:7070,bch2.solofury.com:7070,xec.solofury.com:7070, or theireu-/asia-regional equivalents. - What’s the worker username? Must be
<wallet_address>.<worker_name>. The wallet address must be valid for the coin (BCH CashAddr for BCH/BCH2, P2PKH/Bech32 for BTC, eCash for XEC, etc.). - From the ASIC, can you reach the pool? Use ASIC’s diagnostic tools or ping/telnet from another machine on the same subnet.
Most common root cause: wrong wallet format
Each SoloFury coin requires a wallet in its native format:
| Coin | Format | Example |
|---|---|---|
| BTC | Bech32 or P2PKH | bc1q... or 1... |
| BCH | CashAddr (with prefix) | bitcoincash:qq... |
| BC2 | BTC-compatible | bc1q... or 1... |
| BCH2 | CashAddr (with prefix) | bitcoincash:qq... |
| XEC | eCash (with prefix) | ecash:qq... |
7. Symptom: Best Share Stuck Low (Worried You Won’t Find a Block)
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 Poisson process most shares are small, and the maximum grows slowly with the cube root of total work done. A low best share is statistically normal.
What matters for block-finding probability is total cumulative hashrate-time, not best share. If your hashrate is good and your reject rate is low, you are buying lottery tickets correctly — variance just takes time to express.
For the math behind solo mining variance and what to realistically expect at different hashrate levels, see the Solo Mining Lottery Math article.
8. Quick Reference: Symptom → Most Likely Cause
| Symptom | First thing to check | Most common cause |
|---|---|---|
| Hashrate 20%+ below expected (steady) | ASIC local UI | Hashboard or thermal issue |
| Hashrate fluctuates wildly minute-to-minute | This is normal for small workers | Variance, wait for 1h average |
| Reject rate above 2% | Ping to pool | Latency — switch region |
| Stale rate above 2% | Ping to pool | Latency — switch region |
| Worker offline (“Last seen: hours ago”) | ASIC power & network | Power loss or stratum config error |
| Frequent disconnects | Router/NAT, ISP | Use HAProxy regional endpoint |
| Best share very low after weeks | This is statistical | Normal, keep mining |
| Hashrate climbing slowly after start | Vardiff converging | Wait 30 minutes, normal behavior |
9. Choosing the Right SoloFury Region
Pool latency is the single most controllable factor for share quality. SoloFury operates three regions:
| Region | Endpoint pattern | Best for |
|---|---|---|
| Atlanta (primary) | <coin>.solofury.com | North America, Caribbean, South America east coast |
| Frankfurt (EU relay) | eu-<coin>.solofury.com | Europe, Middle East, Africa |
| Singapore (Asia relay) | asia-<coin>.solofury.com | Asia, Oceania, India |
Test your latency by replacing <coin> in each endpoint and pinging from your network. Pick the lowest. If two are close, prefer the one with lower jitter (variance in ping times), not just lower average.
10. When to Reach Out
If your worker is showing one of these symptoms after you’ve worked through this guide:
- Multiple workers all dropping simultaneously, only on SoloFury (not other pools)
- All workers showing zero shares despite ASIC UI confirming hashing
- Block found in Hall of Fame but reward never reached your wallet
…contact SoloFury support via the Telegram bot or @SoloFuryPool on X. Provide:
- Your wallet address (so support can look up your worker history)
- The coin you are mining (BTC/BCH/BC2/BCH2/XEC)
- The worker name showing the symptom
- The endpoint URL configured in your ASIC
Most issues resolve in under 30 minutes once support has the worker name.
Next Steps
- Run the Miner Health Check guide for a full diagnostic walkthrough of a misbehaving ASIC
- If you’re setting up a new miner, see the Antminer S21+ Setup Guide or the Antminer S19 & Whatsminer M-series Setup Guide
- For rental hashrate diagnostic differences, see the NiceHash Solo Mining guide
- For background on share difficulty math, read the Solo Mining Variance article
- For real-time pool status, check the System Status page