Miner Log Reader — How to interpret your SoloFury miner report

The SoloFury Miner Log Report is a complete textual snapshot of your solo-mining activity, generated on demand from the /miner/ page. It includes real-time hashrate, per-worker health diagnosis, share quality, difficulty optimization suggestions, 24-hour statistics with ASCII chart, blocks found, and pool/network context — all in one self-contained .log file you can save, share, or feed to scripts.

Unlike a dashboard screenshot, the log is structured text you can save for historical records, share with support, parse with scripts, or attach as evidence in case of pool issues.

How to download your log

1. Open solofury.com/miner/ with your wallet in the URL: ?addr=YOUR_WALLET&coin=COIN
2. Wait for the dashboard to fully load (3–5 seconds — the report uses live API data)
3. Click the .LOG button in the top-right of the identity card
4. Your browser downloads a file named solofury-COIN-WALLET-DATE.log

1. Executive Summary

A one-glance overview: status, workers, current hashrate vs 24h average, blocks lifetime, total mined, and top issues. Read this first — it tells you whether there’s anything to investigate.

Status values

• ✓ ALL GOOD — every worker is healthy, no degradation above 25%
• ⚠ ISSUES DETECTED — one or more workers have warnings (drops 25–50%, late shares 3–10 min)
• ⚠ CRITICAL — one or more workers are offline (>10 min) or severely degraded (>50%)

The “Top issues to investigate” lists the most urgent items. If your report is ALL GOOD, you can stop reading here and check back tomorrow.

2. Overview

Wallet-level aggregated stats:

• Hashrate snapshot — moving averages on different time windows. The 1m is most volatile; the 7d is the most stable benchmark.
• Workers / ASIC online — count of active miners.
• Shares (lifetime) — totals since your wallet first connected. Accepted/rejected/invalid/stale/duplicate breakdown.
• Efficiency — % of submitted shares accepted. Target: 99.9%+.
• Luck (round) — your luck for the current block round. Above 100% means you’ve already submitted more shares than statistically expected for finding a block.
• Best share / Best ever — your highest-difficulty share. Closer to network target = closer to finding a block.

3. Worker Health Analysis

This is the most important section for troubleshooting. The analyzer compares each worker’s current hashrate against its 1h and 24h moving averages, plus checks how recently it submitted a share.

Severity levels

What to do — typical cases

• Offline > 10min — check power, network cable, stratum URL still reachable
• Hashrate −50% or more — likely thermal throttling or hashboard failure; check cooling first
• Hashrate −25 to −50% — mild degradation, monitor for 30min before acting
• Late shares but normal hashrate — network/stratum issue; check the relay (Frankfurt/Atlanta/Singapore) you’re connected to

The log includes suggested actions for each problematic worker, customized to the specific issue.

4. All Workers (table)

Full tabular view of every worker, regardless of status. Useful for comparing performance side-by-side.

Columns explained

• HASHRATE / 1H AVG / 24H AVG / 7D AVG — different time-window averages. The 7d shows your “true” capacity.
• UPTIME — total time the worker has been connected (since first share).
• BEST DIFF — the highest-difficulty share this worker has ever submitted. Higher = closer to a block.
• LAST SHARE — time since the worker submitted its last share. Should be <1min in normal operation.
• STATUS — current health (see section 3).

5. Difficulty Optimization

The pool uses vardiff (variable difficulty): it automatically tunes the share difficulty so each worker submits roughly 1 share every 10 seconds. This section shows whether the current difficulty is optimal.

Formula

optimal_diff = hashrate × 10 / 2³²

Actions

• ↑ raise +X% — current diff is too low; you’re flooding the pool with low-value shares. Pool will adjust automatically (or you can set password=d=NUMBER manually).
• ↓ lower −X% — current diff is too high; you’re submitting too few shares for smooth tracking. Especially relevant for low-hashrate Bitaxe.
• ≈ already optimal — no action needed.

6. Share Quality Analysis

Breakdown of share rejections by type:

• Reject — submitted but invalid (wrong target, bad work). Often points to network corruption or firmware issues.
• Invalid — malformed share. Should be near-zero.
• Stale — share for an outdated block (your miner was still on the previous block when a new one came in). Some staleness is normal; >1% suggests latency to the pool.
• Duplicate — same share submitted twice. Usually a network glitch.

Quality badges

• ⭐ Excellent — total bad-share rate < 0.1% (one share in a thousand or rarer)
• ✓ Good — bad-share rate < 1%
• ⚠ Below normal — bad-share rate > 1%; investigate network or firmware

7. Statistics (last 24h)

Aggregated metrics from the 24h chart endpoint (samples every 5 minutes):

• Hashrate avg / max / min — daily range. Big gap between min and max suggests instability.
• Peak vs avg — how much spikier than average were your peaks. <20% is smooth; >50% suggests on/off behavior.
• Effective uptime — % of samples that had hashrate above 10% of average. 100% means continuous operation.
• Shares 24h — daily share counts. Compare with your usual baseline to spot regressions.

8. Wallet-Level Outages

Lists total-wallet blackouts in the last 24h, where the entire wallet’s hashrate dropped below 15% of its average. This catches cases like:

• Power outage at your mining facility
• Network failure on your side
• Pool-side outage (rare, but possible)

Per-worker issues (when only one of several miners fails) are not shown here — those are in section 3.

9. Hashrate Timeline (24h)

Two-part view of the 24-hour hashrate evolution:

• ASCII chart — a quick visual sketch of the hashrate curve. Y-axis labels show absolute values; X-axis spans 24h ago to now.
• Hourly snapshots — one row per hour, showing both your hashrate and the network difficulty at that moment.

Use this to spot patterns: daily/weekly cycles, slow declines, sharp drops.

10. Blocks Found by this Wallet

Real list of blocks your wallet has found on this pool. Each entry shows:

• HEIGHT — blockchain block height (verifiable on any block explorer)
• DATE — UTC timestamp of the block
• WORKER — which specific worker submitted the winning share

This data is fetched from the pool’s blocks API filtered by your wallet address.

11. Network Context

The wider blockchain context for your coin:

• Network hashrate / difficulty — current totals across the entire blockchain.
• Your share of net — fraction of the network’s total hashrate you contribute.
• Statistical TTF — Time To Find the next block, statistically. Computed as 1 / (your_HR / network_HR × blocks_per_day). Real luck varies wildly: you might find a block in 1 hour or take 10× the statistical TTF.

12. Pool Context

SoloFury pool-wide stats: hashrate, miners, workers, idle/disconnected counts, fee, luck, uptime. Use this to verify the pool is healthy when troubleshooting your own setup. If pool stats look normal but your miner shows issues, the problem is on your side.

Frequently Asked Questions

How often should I download a log?

For active monitoring: once a day or whenever you notice abnormal behavior. For historical records: weekly or monthly. The log is small (~10–50 KB) so storing many is fine. The unique Report ID in the header lets you reference specific reports in support emails.

Can I script the .log generation?

Not directly (the button triggers client-side JS), but you can fetch the same underlying API data: https://solofury.com/api/client/YOUR_WALLET, /api/pool, /api/client/YOUR_WALLET/chart?range=24h. All return JSON. You can build your own report from these endpoints in any language.

The log says my worker has a hashrate drop but the dashboard looks normal — why?

The “now” value can spike up briefly while the 1h/24h averages stay lower (they’re rolling windows). If “now” > “1h avg” but the log warns about drop vs “24h avg”, it means your worker’s been running below capacity for most of the day but just spiked back up. The log compares against the longer-term reference to catch sustained issues.

The “Statistical TTF” says 30 days — does that mean I’ll find a block in 30 days?

No. Statistical TTF is the average expected time. Due to the exponential distribution of block-finding, you have a ~63% chance of finding a block within 1 TTF (30 days here), ~86% within 2 TTFs (60 days), and ~95% within 3 TTFs (90 days). Some weeks you’ll find two blocks, others none. This is the nature of solo mining.

What’s the difference between “Rejected” and “Invalid” shares?

Rejected: the share was valid in format but didn’t meet the target difficulty (often due to stale work or low diff). Invalid: the share was malformed (wrong format, bad nonce). Invalid is almost always a software/firmware bug. Rejected can be normal in small amounts (network latency).

I see “LATE share” but my worker is mining — what’s wrong?

“LATE share” means >3 min since the last share. Possible causes: network drop to the stratum, very high difficulty (low share frequency expected), or the miner is offline but the pool hasn’t fully detected yet. Cross-check with the dashboard hashrate. If hashrate is still showing, it’s usually a transient connectivity issue.

Where can I get more help?

Email [email protected] with the .log file attached. Include the Report ID from the header — it helps us correlate with our server-side logs. The pool team aims to respond within 24h.