This Bitcoin mining handbook is for the period after an ASIC has passed commissioning. It sets an operating rhythm for daily monitoring, weekly reconciliation, planned maintenance, firmware control, pool and payout security, financial review, incident response and end-of-life decisions. It deliberately does not repeat a first-installation guide or promise profitability; its purpose is to keep a working fleet measurable and accountable.
Build the fleet register
Reassess Bitcoin mining handbook whenever network conditions, firmware, tariffs or official guidance changes.
Record every serial, model, variant, site, rack or position, PSU, controller, firmware, pool worker, warranty, purchase date and ownership. Link parts and repair history to the same asset.
Store payout destinations and credentials in controlled systems, not the general register. The register can identify the approved account without exposing secrets.
Add rated and measured stock performance, normal temperature range and safe site limit. These values make future alerts specific to the machine rather than generic.
Keep a change and movement history. If a machine moves site, retest circuit, cooling, network and accepted baseline.
Daily operating checks
When reviewing Bitcoin mining handbook, separate measured facts from forecasts so the result can be reproduced.
Review powered and accepted worker count, pool accepted hashrate, rejects, temperatures, fan or pump state, restarts and alerts. Compare with the same time window and known curtailment.
Investigate a missing worker before assuming it is a pool display delay. Check site power, controller, network and pool status through independent evidence.
Look for trends, not only red thresholds. Rising fan speed at the same inlet temperature can indicate restriction; slowly falling accepted work can precede a full board fault.
Record actions and owners. A warning acknowledged by several people but assigned to nobody remains unresolved.
Weekly revenue and energy reconciliation
| Measure | Source | Decision |
|---|---|---|
| Accepted work | Pool worker export | Output and anomaly |
| Energy | Site or circuit meter | Efficiency and cash cost |
| Rejects | Pool categories | Network or tuning fault |
| Availability | Power and accepted records | Uptime and service issue |
| Credit | Pool statement and wallet | Revenue reconciliation |
| Maintenance | Work order and parts | Reserve and repeat fault |
Calculate accepted efficiency over matched periods. Divide measured watts by accepted terahashes for SHA-256, or use the appropriate algorithm unit. Do not mix a local peak with a monthly meter.
Reconcile pool credit after the stated method and maturity. Keep bitcoin production separate from sterling price movement so technical and treasury issues remain visible.
Maintenance without creating faults
Follow manufacturer and site procedures for cleaning, filters, fans, pumps, heat exchangers, connections and firmware. Isolate safely and use competent people for electrical work.
Do not use compressed-air methods that drive contamination deeper, overspeed fans or create unsafe dust exposure. The suitable method depends on equipment and environment.
Keep approved spare parts and record serial or board swaps. A repaired mixed unit may require different firmware or acceptance evidence.
After maintenance, run a stock acceptance check and compare with the pre-work baseline. Close the work order only when pool and site evidence agree.
Firmware and access governance
Maintain an approved image list by exact model and controller. Record source, checksum where supplied, release notes, licence, developer fee and recovery method.
Test one non-critical miner before staged deployment. Do not combine a firmware release with a pool and electrical change because rollback evidence becomes ambiguous.
Remove default credentials, restrict management networks and use controlled remote access. Monitoring staff do not automatically need pool, wallet or firmware authority.
Review leavers, recovery codes, cloud accounts and outbound destinations. A secure machine can still be compromised through its email or management platform.
Financial and lifecycle review
Update revenue, difficulty, tariff, pool fee, cooling, repair and uptime assumptions at a documented interval. Use a downside case and current accepted performance.
Separate avoidable cash margin from capital recovery. A paid-for miner can be rational to run while it covers avoidable cost, but that does not prove the original investment succeeded.
Compare major repair with reasonable used value and expected remaining contribution. Do not fit a costly board because the machine was once expensive.
Set keep, tune, repair, relocate, curtail and retire categories with review dates. Include freight, insurance, data removal, resale and recycling in exit decisions.
Incident response
- Protect life and site safety, then isolate affected equipment through the approved procedure.
- Record time, asset, firmware, pool, power, network and last known good state.
- Preserve logs before mass reboot or configuration replacement.
- Verify payout, pool and account changes from a clean controlled device.
- Use only approved backup endpoints and recovery images.
- Notify host, insurer, supplier or authority where contract or law requires it.
- Test the remedy at stock settings before restoration.
- Complete root cause, financial impact and prevention review.
Monthly management questions
Is the fleet controlled
Confirm asset register, access, payouts, firmware, alarms, maintenance and incident actions are current. A dashboard without an accountable owner is not a control system.
Review concentration in one pool, one site, one energy contract and one firmware provider.
Is the fleet still economically useful
Use accepted efficiency and complete cost under a cautious case. Compare curtailment and upgrade choices with real contracts and exit value.
Retire equipment that cannot operate safely or has no justified repair and revenue route.
Frequently asked questions
Which hashrate belongs in an operating report?
Use pool accepted work over the same period as energy and uptime, with local hashrate retained for diagnosis.
How often should profitability be recalculated?
Use a regular documented cycle and update sooner when revenue, difficulty, energy, fees or condition changes materially.
Should firmware be automatic?
Only under an approved policy with exact compatibility, staged testing, recovery and security controls. Uncontrolled automatic change can create fleet risk.
What spare parts should be held?
Base stock on fleet models, failure history, lead time and repair capability. Fans, PSUs, pumps and cables are common examples, but exact needs vary.
When is an ASIC beyond economic repair?
Compare total repair and downtime cost with reasonable used value and expected remaining contribution under current conditions.
What records should be retained?
Keep assets, work, energy, pool, wallet, invoices, changes, maintenance, incidents and approvals for the periods required by law and policy.
Conclusion
A Bitcoin mining handbook earns its place by creating a repeatable operating rhythm. Register the fleet, reconcile accepted work and energy, maintain through controlled procedures and protect every configuration and payout change. Then reassess economic usefulness rather than allowing a once-profitable machine to run indefinitely without evidence.
Next steps
Use The Mining Shop UK profitability, safety, hosting and repair resources during the fleet’s scheduled monthly review.
Conclusion: Bitcoin mining handbook
Use pool accepted work, metered energy, temperatures, rejects and uptime as the daily operating record. Local hashrate alone is incomplete. Separate monitoring, configuration and payout authority. Plan maintenance and firmware as controlled changes with recovery paths.
Sources and further reading
- Bitcoin developer mining guide: Primary reference for Bitcoin mining work and pool shares.
- HSE electrical maintenance guidance: Primary UK guidance on maintaining electrical equipment and systems.
- NCSC device security guidance: Primary UK cyber-security guidance for connected devices.
