Why can a CKPool hashrate window lag when shares are sparse?
Use the one-hour rate, a recent last share, and the published difficulty to explain a lagging display. The whole-service file is not your address. Do not read 0 or offline as a paid 0 BTC.
Separate the miner's local rate from the pool's one-hour window
If the local rate is healthy and the page shows 0, wait for a share above difficulty 10000. Do not treat that as a balance.
| Reading | How to read it |
|---|---|
| One-hour hashrate | The window the monitor shows for the address and each Worker |
| A shown 0 | A rate of 0 in that hour, not unpaid coins |
| Last share older than about 10 minutes | Marked offline. That is a share gap, not a device heartbeat |
| Whole-service pool.status | A total for the whole service, not this address's rate or balance |
The rate on the miner panel and the rate on the Bitcoin monitor can disagree. For this address and its Workers, the monitor shows a one-hour window. Units run from K through E, and no letter means H/s. pool.status is a whole-service file, and it also carries shorter and longer windows for the service as a whole. Those totals describe the service, not this one address's hashrate, and not BTC owed to you. Do not copy a whole-service reading onto your account.
Why shares are sparse
The FAQ states a minimum difficulty of 10000. When hashrate is too low, statistics do not show until a share is detected, and the service then adjusts toward the hardware. Software that supports client-diff may set it as low as 1. That does not change the chance of finding a block, because shares here are feedback only. Below 100GH is not a recommended way to expect a block. Those sentences explain why a display can lag.
Online follows the last share
The user record has no separate online switch. A last share no older than about 10 minutes is online, and an older one is offline. A missing share time is unknown. A machine can still be hashing and look offline once the gap exceeds about 10 minutes. Empty amount fields stay unknown. Do not read offline as a paid 0 BTC.
Two illustrative branches
Suppose one row has a last share 11 minutes ago and a one-hour rate shown as 0. The page marks that row offline, and that hour's rate is 0. Branch one: the miner panel still shows a healthy local rate. That fits "no share has landed above difficulty 10000" better than "0 BTC was paid." Keep watching the connection to stratum.ckpool.org port 3333 and wait for the next share. Branch two: the miner's own rate is also 0. Then check power and the pool host. The balance is still unpublished, so do not read it as 0. Both numbers are an illustration, not a measurement.
Read this window on the Bitcoin monitor. How to read the page is in address monitor. Naming is in address and Worker names.
Common questions
Why can a running miner show 0?
When no share lands in the one-hour window, the rate can show as 0. That is not an amount paid.
Does client-diff 1 make a block more likely?
The FAQ says no. Shares are feedback only. The value may be as low as 1 and does not change the chance of a block.
Is the hashrate in pool.status mine?
No. That file is the whole service. Your address is read as a one-hour rate on the monitor. A service total is not a personal balance.