Treat mining as an operating system
A working miner is one part of a larger setup. Electrical supply, heat management, networking, pool configuration, monitoring, maintenance, and payout arrangements all need owners. A machine can be powered on while failing to deliver accepted work, and a pool can show work while a payout configuration still needs attention.
Write down the responsibilities before the first startup. Who can access the location? Who receives alerts? Who is authorized to change settings? Who can shut down the equipment safely? For a hosted machine, ask which responsibilities belong to the provider and which remain yours. Keep those answers in the service agreement rather than relying on a sales conversation.
Start with the exact equipment documentation and the intended pool’s current setup guide. Braiins’ Bitcoin setup reference is an example of provider-specific configuration guidance. Different services can use different endpoints, worker conventions, payout settings, and account controls, so copying another operator’s configuration is not a substitute for checking yours.
Process in three steps
- Prepare the site. Resolve electrical suitability, ventilation or cooling, networking, physical access, and the safe shutdown plan before applying power.
- Commission and verify. Follow the model’s instructions, configure the intended pool, and confirm that the correct account receives accepted work. Record a baseline.
- Monitor and maintain. Compare consistent operating periods, investigate deviations, and schedule documented maintenance rather than waiting for failures.
Keep a simple change log with date, reason, settings changed, and observed outcome. When performance changes later, the log helps distinguish a configuration effect from a connection problem, site condition, or equipment fault. Avoid changing several unrelated settings at once if you want to understand the result.
Key vocabulary
- Uptime: The portion of a defined period spent in the operating state being measured. Specify whether that means powered, hashing, or delivering accepted work.
- Accepted work: Submissions credited under the pool’s rules. A local hashrate display does not establish that every attempted submission was accepted.
- Rejected or stale work: Submissions not credited as valid work under the relevant rules. Investigate persistent changes using the provider’s explanations and logs.
- Baseline: Recorded normal behavior under known settings and site conditions. It provides a comparison for later troubleshooting.
The Braiins shares reference explains the accounting distinction between pool work and network blocks. Use the actual pool’s documentation when interpreting its dashboard, because terminology and reporting windows can differ.
Prepare power, heat, and connectivity
Have a qualified electrical professional assess the proposed installation against the equipment requirements and local rules. Keep electrical documentation available to the person responsible for the site. A profitability calculation or the fact that a plug fits does not establish that the supply is suitable for sustained operation.
Identify the path for heat removal and the equipment’s required operating environment. Check the model’s documented limits and whether the cooling arrangement is air, liquid, or another specified system. Do not assume a temperature range from one product applies to all miners. BITMAIN’s product setup guidance is a reference for those named models, not a universal site standard.
Plan networking and account access together. Record the approved pool endpoints and account or worker names, protect credentials, and understand how to recover access. Verify payout addresses independently. Use available account security controls and restrict configuration access to the people who need it. Keep access recovery information securely; it does not belong in a public maintenance log.
Monitor the complete chain
Compare the miner’s status with pool-side accepted work and account-side payouts. Look at the same time window before deciding that two figures disagree. Short windows can be noisy, and a device reading may represent a different averaging period from the pool’s estimate.
Create alerts around sustained deviations from your baseline: no accepted work, unexpected restarts, connection failures, or environmental readings outside documented limits. Choose thresholds based on the actual machine and site. There is no single universal alert value that makes every installation safe or profitable.
For troubleshooting, collect the time of the event, device identification, recent changes, logs, and relevant measurements. Check whether the issue affects one machine or the whole site before replacing parts. Escalate with that evidence to the responsible provider or manufacturer, keeping credentials and private account information out of screenshots shared publicly.
Maintenance and safe shutdown
Use the model’s service instructions to define inspection, cleaning, and maintenance responsibilities. BITMAIN’s handling guidance covers precautions for its equipment. Do not open powered equipment or improvise repairs from a generic article. Follow the applicable isolation and service procedure with qualified help where required.
Plan for spares, repair logistics, and downtime costs. Ask a hosting provider how a failed unit is identified, who approves repair, and how charges continue during downtime. Keep written records of incidents and returned equipment so later condition assessments have a history.
Worked example
Hypothetical availability check
In a 30-day period there are 30 × 24 = 720 hours. If accepted-work operation totals 684 hours, measured availability is 684 ÷ 720 × 100 = 95%.
The remaining 36 hours should be classified: planned shutdown, connectivity problem, repair, or another documented cause.
This example measures a defined operating state. It does not show whether the equipment earned a profit or whether the downtime was avoidable. Keep the definition consistent between months, and avoid presenting powered-on hours as accepted-work hours unless the evidence supports that interpretation.
Use the incident categories to improve your plan. A scheduled price-related shutdown raises different questions from a recurring network failure. Update calculator uptime assumptions from records rather than automatically leaving them at 100%. The mining return estimator can show the effect of a changed assumption, but cannot diagnose the underlying cause.
Common mistakes
- Watching only the machine dashboard. Verify that work reaches the intended pool and that payouts are configured for the correct account.
- Using generic maintenance rules. Follow the exact model’s documentation and site procedure rather than copying limits from unrelated equipment.
- Assuming perfect availability. Record downtime and its cause, then use realistic operating assumptions in planning calculations.
Frequently asked questions
How often should equipment be cleaned?
Use the manufacturer’s guidance and the site’s conditions to establish a schedule. Document inspections and any changes in operation; a universal cleaning interval cannot account for every environment and product.
Should I restart whenever reported hashrate falls?
First compare the same reporting windows and inspect logs, accepted work, and recent changes. Repeated restarts can hide evidence without resolving the cause. Follow the provider’s troubleshooting process and the equipment instructions.
What should I learn next?
Revisit energy and power for site cost assumptions and hardware for model-specific questions. The home mining safety checklist provides related reading, while hosting locations can support provider research if you are comparing managed sites.