Stop the Bleed - Why Your Miner API is Only Telling Half the Story

A miner can report normal temperatures, fan speed and local hashrate while the pool records less accepted work. That gap is not a theoretical detail. In a large fleet, a small and persistent difference can become a material revenue leak, especially after the halving when every unit of energy has to earn its place.

The blind spot is a measurement problem

Local APIs answer a useful question: what does the machine report about its current state? They do not answer the complete commercial question: how much hashrate did the pool accept and attribute to the right account? Network latency, stale or rejected shares, an incomplete API response, a wrong sub-account, or a temporary data gap can make those two views diverge.

This is why “online” should not be treated as a proxy for “earning.” A practical review starts by comparing the local view with the pool view at the same farm, customer and sub-account level. The result is a reconciliation workflow, not a new vanity metric.

Question	Local monitoring	Pool-side monitoring
What is measured?	Miner-reported state and local hashrate	Accepted hashrate and pool online status
What can it reveal?	Temperature, fan, reject rate, API exceptions	Yield gap, missing observer data, sub-account attribution
What is still needed?	Economic comparison against pool data	Local context to diagnose the cause

Use hashrate compliance as a diagnostic signal

ItsMiner’s pool module combines the theoretical hashrate entered for a sub-account to calculate Hashrate Compliance Rate. The simple relationship is:

Hashrate Compliance Rate = Pool Hashrate / Theoretical Hashrate × 100%

The metric is useful only when its inputs are understood. If either value is unavailable, the product displays “-”. A low rate is a prompt to investigate, not proof of one specific hardware fault. Operators should check the local miner list, API-exception markers, board status, reject rate, sub-account configuration and the timing of the pool sample before deciding what to do.

At farm and sub-account level, teams can configure online-rate and compliance-rate thresholds. They can also configure a hashrate-difference alert based on the absolute gap between pool and local hashrate. The farm-level difference threshold cannot be set below 500 TH/s; sub-account thresholds have a different rule. Alerts can be delivered through the configured SMS, email or Telegram channels, while pool data-fetch failures are sent through the Feishu notification path.

The time axis matters more than a single screenshot

A one-time comparison can be distorted by sampling time, a pool’s averaging window or a brief monitor outage. ItsMiner records hourly pool and local snapshots, and its Dashboard and pool module provide 10-minute, hourly and daily curves. The hourly record is built from six 10-minute pool points and the corresponding local points, so an operator can ask whether the gap is persistent, intermittent or confined to one collection window.

The same review should include data quality. An expired or invalid observer link, a failed pool fetch, or a miner API exception changes what can be concluded. The product surfaces these conditions instead of silently treating missing data as zero performance. That distinction is essential when a team is calculating a loss estimate or discussing a customer dispute.

Turn a gap into an accountable operating loop

A useful operating loop is straightforward: first, verify the observer link and the theoretical-hashrate baseline; second, compare pool and local curves by farm, customer and sub-account; third, filter the miner list for API exceptions, board abnormalities, reject rate and configuration issues; fourth, record the action and re-check the next comparable time window.

Configuration is often the least dramatic and most expensive source of leakage. ItsMiner can identify miners that are not using an allowed sub-account configuration, and its whitelist and automatic sub-account recovery rules can restore a previous or specified configuration when the relevant policy is enabled. These are controlled write operations and their results are retained in Operation Records. That is different from claiming that every hashrate gap is automatically repaired.

For an illustrative scenario only, assume a 3.3 EH/s site and a sustained 2% gap. The gross value of that gap depends on BTC price, network difficulty, pool terms and energy cost; it should be calculated from the site’s own settlement data. The important control question is not whether a dashboard can show 100% online. It is whether the operator can explain the difference between what the rack reported, what the pool accepted and what action followed.

The operational standard has changed

Traditional monitoring remains necessary. It tells the team where to look. It is not sufficient for proving that the fleet produced the hashrate the business expected to be paid for. The stronger standard is to make local status, pool economics, data quality and follow-up actions visible in one reviewable chain.

ItsMiner supports that chain through local miner monitoring, pool observer-link integration, paired local-versus-pool curves, hourly snapshots, compliance and difference alerts, and auditable configuration operations. It does not replace engineering judgment; it gives the team a more defensible basis for applying it. Before publishing a loss number, use the farm’s actual pool records and settlement assumptions. Before calling a machine healthy, check the economic side of the story.

Contact us for a demo:

• Email: sales@powsell.com
• Telegram: @ItsMinerOfficial