Mining Logs
Mining Logs are records generated by mining software, ASIC controller firmware, or a mining management system that document events related specifically to the mining process. They can contain information about: mining software startup mining pool connections Stratum communication mining jobs worker authorization share submissions accepted and rejected shares hash rate hardware errors hashboard status ASIC initialization pool failover mining process restarts
Mining Logs Explained in Simple Terms
An ASIC can be powered on and reachable over the network without actually mining correctly.
For example, the miner may have:
failed to connect to its pool
failed worker authorization
stopped receiving mining jobs
stopped hashing
started generating excessive errors
failed to submit shares
Mining logs record events associated with this process.
A simplified sequence might look like:
Miner Starts → Pool Connects → Worker Authorized → Mining Job Received → Hashing Begins → Share Found → Share Submitted → Share Accepted
If something goes wrong, the sequence changes.
For example:
Miner Starts → Pool Connection Attempt → Connection Fails → Retry → Backup Pool Selected
Mining logs help operators see where the mining workflow stopped working normally.
How Mining Logs Works
Mining software continuously performs actions while the ASIC is operating.
Important events can be recorded as log entries.
A typical process is:
Mining Software Starts
The miner initializes the processes required for mining.Pool Connection Begins
The software attempts to connect to a configured mining pool.Worker Is Authorized
The pool validates the worker credentials or mining configuration.Mining Jobs Are Received
The pool provides work to the miner.ASIC Hardware Performs Hashing
Hashboards and ASIC chips search for hashes satisfying the assigned share target.Shares Are Submitted
Valid share solutions are sent back to the pool.Results Are Recorded
Accepted shares, rejected shares, errors, reconnections, and other events may appear in the mining logs.
The normal flow is:
Connect → Authorize → Receive Work → Hash → Submit Share → Receive Result → Continue
Example of Mining Logs in Practice
Suppose an ASIC miner appears online in the monitoring system.
Its local interface reports that the hardware is running, but the mining pool shows almost no effective hash rate.
Mining logs might reveal:
Pool Connected → Mining Job Received → Share Submitted → Share Rejected
If rejected shares continue increasing, the operator now knows that the miner is performing work but that the submitted work is not being accepted normally.
The investigation can focus on:
pool communication
mining configuration
network conditions
share rejection reasons
system timing or other relevant software conditions
Without mining logs, the problem might simply appear as poor pool-side performance.
Why Mining Logs Matter
Mining logs provide visibility into the path between the mining hardware and the mining pool.
They help answer questions such as:
Did the miner connect to the pool?
Was the worker authorized?
Is the miner receiving jobs?
Is hashing actually running?
Are shares being found?
Are shares being submitted?
Are shares accepted or rejected?
Did the miner switch to a backup pool?
Did the mining process restart?
This makes mining logs an important troubleshooting tool.
Mining Logs vs Log Files
The terms are closely related, but mining logs are more specific.
Log Files
A broad category covering records from the entire ASIC system.
They may include:
operating-system events
controller events
network events
firmware updates
hardware initialization
security events
Mining Logs
Focus primarily on the mining process.
They may include:
pool connections
mining jobs
shares
hash rate
mining-process errors
mining-process restarts
In simple terms:
Log Files = All Types of System Records
Mining Logs = Records Related to Mining Activity
Depending on the firmware, both types of information may appear in the same interface or file.
Mining Logs and Mining Pools
Pool communication is one of the most important areas recorded by mining logs.
Logs may show:
connection attempt
successful connection
authentication or authorization
connection loss
reconnection
failover to another pool
A normal sequence may look like:
Primary Pool → Connected → Authorized → Jobs Received
If the primary pool becomes unavailable:
Primary Pool Lost → Retry → Backup Pool Connected
This helps operators determine whether mining interruptions are caused by the ASIC itself or by pool/network connectivity.
Mining Logs and Stratum
Bitcoin mining pools commonly communicate with miners using the Stratum family of mining protocols.
Mining logs may record events associated with this communication.
Depending on the implementation, this can include:
establishing a pool connection
receiving mining work
updating jobs
submitting shares
receiving share results
A simplified flow is:
Pool → Mining Job → ASIC Miner → Share → Pool
Mining logs provide a record of events along this communication path.
Mining Logs and Mining Jobs
Mining pools continuously provide miners with work.
A mining job contains information the miner uses to construct or update the data it hashes according to the mining protocol and software implementation.
Mining logs may indicate:
new job received
job changed
previous work replaced
mining restarted on new work
Frequent job changes can be normal.
For example, miners must react when the network tip changes and pools update their candidate blocks.
Mining Logs and Share Submission
ASIC miners perform enormous numbers of hash attempts.
Most hashes do not produce anything that needs to be sent to the pool.
When a miner finds a hash satisfying the pool's assigned share target, it submits a share.
The mining logs may record:
Share Found → Share Submitted → Pool Response
The response can indicate whether the share was accepted or rejected.
This makes share-related logs useful for evaluating whether the miner is successfully delivering useful work to the pool.
Accepted Shares
An accepted share is work submitted by the miner that the pool accepts according to the assigned mining job and share difficulty.
Mining logs may record accepted shares continuously.
A normal stream of accepted shares indicates that:
the miner is hashing
pool communication is functioning
work is being submitted
the pool is accepting that work
However, short-term share arrival is probabilistic, so operators should evaluate performance over an appropriate time period.
Rejected Shares
A rejected share is a submitted share that the pool does not accept.
Possible reasons vary by protocol and pool implementation.
They may include:
stale work
invalid work
duplicate submission
communication-related issues
configuration problems
A small number of rejected shares can occur in normal mining.
A persistent or unusually high rejection rate deserves investigation.
Stale Shares
A stale share is generally work associated with a mining job that is no longer current when the pool receives or evaluates it.
One common reason is latency around job changes.
For example:
New Block Found → Pool Sends New Job → Miner Continues Old Work Briefly → Old Share Arrives → Stale
High stale-share rates can reduce effective mining performance.
Mining logs can help identify when these events occur.
Mining Logs and Hash Rate
Mining logs may contain local hash-rate information.
For example:
current hash rate
rolling average
per-hashboard hash rate
This can help correlate mining-process events with hardware performance.
For example:
Board Disappears → Hash Rate Falls → Share Frequency Falls
However, local hash rate should also be compared with pool-side performance.
Local Hash Rate vs Pool-Side Hash Rate
A miner may estimate its own hash rate based on internal calculations.
The mining pool estimates effective hash rate from submitted shares.
Therefore:
Local Hash Rate ≠ Always Pool-Side Hash Rate
Short-term differences are normal because share discovery is probabilistic.
Persistent large differences can indicate:
rejected shares
stale shares
network problems
unstable mining
incorrect reporting
Mining logs can provide additional context for these differences.
Mining Logs and Hardware Errors
Some mining software includes hardware-error information in its logs.
For example:
ASIC Error Detected → Invalid Result → HW Error Counter Increases
Increasing hardware errors can be associated with:
excessive frequency
insufficient voltage
overheating
unstable ASIC chips
hardware faults
This is particularly useful when evaluating custom tuning profiles.
Mining Logs and Hashboard Problems
Mining logs can sometimes reveal the relationship between hardware problems and mining performance.
For example:
Hashboard 3 Stops Responding → Hash Rate Drops → Share Submission Frequency Declines
The logs provide a timeline.
However, they do not necessarily identify the physical root cause.
Board-level diagnostics may still be required.
Mining Logs and ASIC Tuning
Mining logs are useful when testing ASIC tuning.
Suppose frequency is increased.
The operator can compare:
Before Tuning
stable hash rate
normal error behavior
regular accepted shares
with:
After Tuning
higher local hash rate
increased HW errors
more instability
If higher theoretical performance does not translate into better pool-side performance, the tuning profile may not be beneficial.
Mining Logs and Autotuning
Autotuning systems may record information about tuning decisions.
Depending on the software, logs can include:
tuning start
frequency changes
voltage changes
unstable chips
profile changes
tuning completion
A simplified sequence might be:
Test Settings → Measure Performance → Detect Errors → Adjust → Retest
These records are useful when investigating why a miner received a particular operating profile.
Mining Logs and Pool Failover
ASIC miners are commonly configured with more than one pool endpoint.
If the primary pool becomes unavailable, the miner may switch to a backup.
Mining logs can record:
Primary Pool Lost → Connection Retry → Backup Pool Activated
When the primary pool becomes available again, behavior depends on the miner's configuration and software.
Pool failover logs help explain unexpected changes in mining destination.
Mining Logs and Network Problems
Network problems can interrupt mining even when the ASIC hardware itself is healthy.
Mining logs may reveal:
connection timeout
repeated reconnect attempts
pool unreachable
connection reset
temporary communication loss
For example:
Hashboards Healthy + Local Hashing Active + Pool Connection Repeatedly Lost
suggests a different investigation than:
Pool Connected + Hashboard Missing + Hash Rate Reduced
Mining logs help separate these scenarios.
Mining Logs and Reboots
A miner reboot interrupts the mining process.
After restart, logs may show:
Mining Software Starts → Pool Connects → Authorization → New Job → Hashing Resumes
If a miner repeatedly reboots, the mining logs may reveal repeated interruptions.
However, the exact reason for the reboot may appear in system or firmware logs rather than mining-specific logs.
This is one reason mining logs should sometimes be analyzed together with broader log files.
Mining Logs and Remote Reboot
After a remote reboot, operators can use mining logs to verify that the miner returned to productive operation.
A successful recovery might show:
Reboot → Mining Software Starts → Pool Connected → Jobs Received → Shares Accepted
This is more useful than simply confirming that the miner responds to network requests.
The objective is to restore mining, not merely restore connectivity.
Mining Logs and Auto-Reboot
Automated recovery systems may restart a miner when mining activity stops.
For example:
0 TH/s → Auto-Reboot → Pool Reconnects → Mining Resumes
Mining logs can help determine whether the reboot successfully restored:
job reception
hashing
share submission
Repeated sequences of failure and reboot may indicate a deeper problem requiring diagnostics.
Mining Logs and Watchdog Timers
A watchdog may monitor the mining process.
If mining software stops responding, the watchdog can initiate recovery.
The sequence may appear as:
Mining Process Stops → Watchdog Timeout → Restart → Pool Reconnect → Mining Resumes
Repeated watchdog-triggered interruptions should be investigated rather than treated as normal operation.
Mining Logs and Monitoring Systems
Monitoring systems usually work with structured metrics.
Mining logs provide more detailed event information.
For example:
Monitoring: Pool-side hash rate dropped at 14:32.
Mining Logs: Pool connection was lost at 14:31 and repeated reconnect attempts followed.
Together they provide a clearer picture of the incident.
Mining Logs and Telemetry
Telemetry and mining logs provide different types of visibility.
Telemetry
Usually provides structured measurements:
hash rate
temperature
power
fan RPM
Mining Logs
Usually provide event sequences:
pool connected
job received
share rejected
mining process restarted
A useful troubleshooting system combines both.
Mining Logs and Alert Systems
Mining-log events can potentially trigger alerts.
For example:
Repeated Pool Connection Failure → Alert
or:
Mining Process Restarted Repeatedly → Alert
The exact capabilities depend on the monitoring and logging platform.
Logs can also provide context after an alert has already been generated from telemetry.
Mining Log Timestamps
Timestamps make it possible to reconstruct mining events.
For example:
14:30 → Pool Connected
14:31 → New Job Received
14:32 → Connection Lost
14:32 → Reconnect Attempt
14:33 → Backup Pool Connected
This timeline can be correlated with:
hash-rate telemetry
network monitoring
power events
system logs
Accurate system time is therefore important for troubleshooting.
Mining Log Levels
Mining software may classify messages using levels such as:
debug
info
warning
error
critical
Exact terminology varies.
Debug logging may provide extensive detail but can generate large volumes of data.
Production systems therefore often balance diagnostic detail against storage and processing requirements.
Centralized Mining Logs
Accessing individual ASIC logs does not scale well to thousands of miners.
Mining farms can centralize logs:
ASIC Miners → Log Collection → Central Platform → Search and Analysis
Operators can then investigate questions such as:
Which miners lost pool connectivity?
Which miners repeatedly restarted?
When did rejection rates increase?
Which devices experienced similar errors?
Centralization makes fleet-wide troubleshooting more efficient.
Mining Log Retention
Mining logs may be stored for a limited period.
Retention depends on:
local storage
firmware configuration
log volume
centralized storage
operational requirements
If logs are overwritten too quickly, evidence of an intermittent problem may disappear before technicians investigate it.
Centralized storage can provide longer historical visibility.
Mining Logs and Security
Mining logs may contain operational information such as:
pool addresses
worker identifiers
network information
firmware details
device information
Access to logs should therefore be controlled appropriately.
Logs can also be useful for identifying unexpected changes in:
pool connections
configuration
mining processes
This can provide additional context during security investigations.
Mining Logs at Mining-Farm Scale
At industrial scale, mining logs become part of the broader observability infrastructure.
A simplified architecture is:
ASIC Miners → Mining Logs + Telemetry → Monitoring System → Alerts → Diagnostics
Each component serves a different purpose:
Telemetry → Measurements
Mining Logs → Event History
Monitoring → Visibility
Alerts → Attention
Diagnostics → Root Cause
Together, these systems allow operators to manage large ASIC fleets efficiently.
Benefits of Mining Logs
Mining logs can provide:
pool connection history
mining-job visibility
share-submission records
accepted and rejected share information
mining-process troubleshooting
hash-rate context
tuning analysis
restart history
fleet-wide incident investigation
They are particularly useful when determining whether a miner is actually delivering useful work to its pool.
Limitations of Mining Logs
Mining logs have several limitations.
They may be:
incomplete
firmware-specific
difficult to interpret
overwritten
incorrectly timestamped
excessively verbose
A log entry also represents the software's view of an event.
It does not necessarily prove the physical cause of a hardware problem.
Mining logs should therefore be interpreted together with telemetry, monitoring data, pool-side statistics, and hardware diagnostics.