A mining operations checklist helps miners turn routine observations into repeatable operating records. Its purpose is not simply to confirm that ASICs are online. A useful checklist should help an operator verify that miners are configured correctly, power and cooling conditions are suitable, workers are reaching the pool, rejected shares and hardware alarms are reviewed, and rewards and withdrawals can be reconciled.
The checklist should be detailed enough to support troubleshooting without turning a normal mining workflow into an unnecessary audit process.
1. Define the Basic Scope
Start with enough information to identify the equipment and operating environment. The record should show where the miners are installed, such as the site, room, rack, or container, together with the miner model and quantity. It should also identify the relevant pool account or subaccount, selected payment method, primary pool endpoint and port, firmware version, electricity or hosting arrangement, and the person responsible for routine monitoring.
The level of detail can match the size of the operation. Larger operations may maintain separate commissioning, daily-operations, maintenance, and incident records, while smaller miners can combine these into one practical checklist.
2. Create an Equipment and Configuration Baseline
Before placing miners into normal production, record the configuration that will serve as the baseline for later troubleshooting. This normally includes the manufacturer and model, serial number where asset tracking is needed, firmware version, management IP or hostname, worker name, rack or container position, circuit or PDU assignment, and the primary pool URL and port. If a backup connection is used, record that as part of the baseline as well.
Keeping these details together makes later comparisons easier. If a miner starts disconnecting, reporting abnormal hashrate, or behaving differently after a configuration change, the operator has a known working state to compare against.
Pool connection details should come from current official documentation rather than old third-party guides. ViaBTC publishes current connection information, including regional and SSL options, in its Mining Pools Information.
3. Check Power, Cooling, and Network Readiness
Before commissioning, verify the installation against the ASIC manufacturer's requirements and the site's own engineering procedures.
Power
Confirm that the input voltage matches the miner's requirements and that the circuit, breaker, cables, connectors, and PDU or meter are suitable for the planned load. Any abnormal power alarms should be investigated before the miner is placed into normal production.
For standard device-level efficiency, calculate J/TH from measured miner power and miner-side hashrate over a compatible period:
J/TH = measured miner power in watts / average local hashrate in TH/s
Keep pool-side hashrate separate. It is estimated from submitted shares and is not the standard input for device-level J/TH.
Cooling
Cooling checks should reflect the site's cooling design. For air-cooled miners, this may include inlet and outlet conditions, fan status, airflow, blocked airflow, dust, abnormal noise, and thermal alarms. Hydro or immersion systems may require additional checks such as pump, coolant, leak, or circulation status.
There is no single temperature, humidity, or cleaning threshold that applies to every ASIC and every site. Use the miner manufacturer's specifications and the site's operating procedures as the reference.
Network
Confirm that the miner has reliable Ethernet or network reachability and that DNS, routing, time synchronization, and firewall rules are working where relevant. The configured pool endpoint and port should match the intended pool account, and management access should be available to authorized operators.
If a backup connection is configured, document how the miner is expected to fail over and how that behavior will be verified. This makes it easier to distinguish a normal failover event from a connection problem.
4. Commission Miners in Stages
For a new deployment or major configuration change, staged commissioning can make problems easier to isolate.
For each miner or batch:
- Confirm the miner is reachable after startup.
- Confirm expected hashboards or chains are detected.
- Review hardware, fan, temperature, power, and network logs.
- Record local hashrate and its averaging period where available.
- Confirm the worker appears in the intended pool account or subaccount.
- Review pool-side hashrate after the worker has had enough time to submit shares.
- Review rejected shares and rejection reasons.
- Confirm payout settings before assigning material hashrate.
Mining pools use shares to measure contributed work. A pool assigns miners a lower share difficulty than Bitcoin's network difficulty so miners can submit valid shares frequently. A share proves that work was performed but is not normally a Bitcoin block. Only a submitted hash that also satisfies Bitcoin's much harder network requirement can become a valid block candidate.
See: Bitcoin Developer Guide: Mining
When comparing local and pool-side hashrate, first align the time windows. A short difference does not automatically indicate a miner or pool problem.
5. Create a Daily Monitoring Checklist
A practical daily review should focus on signals that can reveal an operational issue without forcing operators to recheck every configuration item each day. Start with worker and miner status: note offline workers, the approximate outage start time where known, restoration status, and any repeated disconnects or reconnects. Local hashrate, temperatures, fan or pump condition, hashboard or chip errors, power-supply alarms, and thermal throttling can help show whether a problem is occurring on the miner itself.
Pool-side data should be reviewed separately. Compare pool-side hashrate over a meaningful observation window with local hashrate over a compatible period, and investigate persistent differences rather than short-term fluctuations. Rejection rate should also be reviewed together with the reported reason. Stale, invalid, duplicate, and other labels are rejection reasons where the pool reports those categories, so identifying the reason is more useful than looking at the total rejection rate alone.
Site-level conditions provide another layer of context. Power or PDU alarms, network interruptions, cooling issues, planned curtailment, and maintenance can all explain changes that appear at the miner or pool level. Recording these events alongside miner data can shorten troubleshooting later.
Financial records can be reviewed on the same routine without mixing them into technical performance metrics. Pool earnings, external withdrawals, and unresolved payout or reconciliation issues should be tracked as separate records so that an operational problem is not confused with a settlement or transfer issue.
The exact review cadence should match fleet size and staffing rather than being treated as a universal operating standard.
6. Use Alerts With a Response Path
An alert is useful only if someone knows what to check next. For an offline worker, a basic response may be:
- Confirm whether maintenance or curtailment was planned.
- Check power and network reachability.
- Open the miner interface and review logs.
- Review cooling and hardware status.
- Restore service or escalate where needed.
- Confirm pool-side reporting returns to normal.
For a rejection-rate alert, first identify the rejection reason rather than assuming the pool is at fault. The next step may differ depending on whether the issue points to latency, miner configuration, firmware, hardware, or another cause.
ViaBTC provides hashrate, rejection-rate, and worker-status alert functions. Thresholds should be configured around the operation's own normal baseline rather than treated as one universal value. See: How to Set Hashrate or Rejection Rate Notification.
7. Reconcile Mining Rewards and Withdrawals Separately
Do not treat all financial records as the same event.
Keep these records separate: pool earnings show mining rewards credited or settled by the pool; withdrawal history shows BTC sent or scheduled to be sent from the pool; wallet receipts confirm BTC received by the destination; and electricity or hosting invoices record operating costs for the stated billing period.
A pool balance is not the same as a completed withdrawal, and a withdrawal is not the same as a fiat sale. Keeping these records separate also helps avoid double counting.
The selected payment method should be recorded because it affects how short-period earnings should be interpreted. At ViaBTC, PPS+ uses PPS for the block-reward component and PPLNS for transaction-fee rewards, while PPLNS applies PPLNS rules to both components.
See: ViaBTC: How Are Profits Calculated?
8. Record Maintenance and Configuration Changes
Material maintenance or configuration changes should leave enough history for later troubleshooting. Record the date, miner or batch affected, the prior and new configuration, work performed, person responsible, and the result after restart. Where rollback is possible, include the relevant rollback information as well.
This history becomes more useful over time. Repeated problems tied to the same miner model, firmware version, switch, power circuit, or cooling zone can reveal a pattern that would be difficult to identify from isolated incidents.
9. Review the Checklist After Material Changes
A mining operations checklist should change when the operation changes. A new miner model, firmware rollout, electrical or cooling modification, pool migration, payment-method change, or a change in hosting or operating procedures may introduce checks that were not relevant before.
The goal is not to make the checklist longer after every change. Review it periodically and keep only the items that help operators verify the current setup, identify abnormalities, and maintain useful records.
A Simple Mining Operations Checklist
The sections above explain why each check matters. The condensed version below can be used as a practical operating reminder without repeating the full troubleshooting logic.
Before commissioning
- Correct miner model and firmware recorded
- Power requirements verified
- Cooling conditions checked
- Network connectivity confirmed
- Official pool URL and port configured
- Worker name verified
- Backup connection reviewed where used
- Payout settings checked
After startup
- Miner reachable after startup
- Expected hashboards or chains detected
- Local hashrate is within the expected range after the miner has stabilized
- Worker appears in the intended pool account or subaccount
- Pool-side hashrate reviewed after a suitable observation period
- Rejected shares and rejection reasons reviewed
- No abnormal temperature or hardware alarms are present
Daily
- Offline workers reviewed
- Local and pool-side hashrate checked over appropriate time windows
- Rejection rate and rejection reasons reviewed
- Temperature and hardware alarms checked
- Site power, network, and cooling alarms reviewed
- Mining earnings and unresolved payout issues checked
Periodic
- Maintenance history reviewed
- Firmware and configuration changes recorded
- Electricity or hosting cost reviewed
- Payout reconciliation completed
- Recurring incidents investigated
Conclusion
A useful mining operations checklist keeps miner-side data, pool-side data, site conditions, and financial records separate. It should make it easy to determine whether the miner is operating normally, whether work is reaching the pool, whether power, cooling, and network conditions are suitable, and whether mining rewards and withdrawals can be reconciled correctly.
Keeping the checklist practical and evidence-based makes it easier to detect problems without adding unnecessary process.
FAQ
Should local hashrate match pool-side hashrate exactly?
No. Local and pool-side hashrate may use different measurement methods and averaging windows. Compare them over compatible periods before treating a difference as abnormal.
Can pool-side hashrate be used to calculate standard J/TH?
No. Standard device-level J/TH should use measured miner power and miner-side hashrate over a compatible period.
How often should a mining operations checklist be reviewed?
Operational checks may be performed daily, while maintenance and financial reconciliation can be reviewed periodically. The appropriate cadence depends on fleet size, staffing, and the operating model.
Why should pool earnings and withdrawals be recorded separately?
A pool credit and an external BTC transfer are different events. Keeping them separate makes reconciliation clearer and helps avoid double counting.