How the pool status checks work

What we send

To each endpoint's stratum port: a TCP connection, a TLS handshake with the certificate checked (TLS ports only), then exactly one mining.subscribe, which names us with this user agent:

SoloLuckLatency/1.0 (+https://sololuck.io/latency)

We read the pool's reply to that request and close the connection. We never send mining.authorize, never mine, never submit a share and never answer anything the pool sends. The same probe also reads robots.txt on the pool's website, at most twice a day, only to honour an opt-out. More about the probe itself: SoloLuckLatency.

From where, and how often

  • From one home internet connection in Java, Indonesia. Not a data centre, not your connection, and one line only: a route that fails between us and a pool may work for you, and the other way round.
  • Status checks, every 10 minutes. One connection to each endpoint on these pages, and a second one about 30 seconds later if the first gets no answer. A check is answered when either connection gets the pool's reply.
  • The latency collector's runs, a few times a day. Up to five connections to each endpoint, about a minute apart. A run counts as one check per endpoint, answered when any of its connections got a reply, and is timed at the moment the run started.
  • One connection at a time, never two to any pool at once, with at least a second and a half between connections.

Right now: the pages are checked every 10 minutes.

What the three states mean

  • Up. The newest usable check was answered.
  • Not answering. The last 2 usable checks in a row got no answer, at least 5 minutes apart, and with no gap longer than 35 minutes between them. It means our probe got no answer from here, and says nothing about how the pool looks from anywhere else.
  • No reading. Everything else: not checked yet, no usable check in the last 30 minutes, only one unanswered check so far, or only checks we set aside. A missed check is never shown as not answering.

Checks we set aside. When, in one run, at least half of the pools got no answer at any of their endpoints, the likelier fault is our own line, so that run's checks count as no reading for every pool. With fewer than 3 pools in a run, any unanswered pool sets the run aside.

The bars. One per hour (UTC) over the last 24 hours. Its height is the share of usable checks answered in that hour; an hour with no usable check is drawn flat and says nothing about the pool.

Reply time. From sending mining.subscribe to the pool's reply, measured on our line. It is not what your miner sees, and it is not odds: every solo pool gives a miner the same chance of a block.

Which pools

Every Bitcoin solo pool the Solo Mining Census reads, SoloLuck included, listed in alphabetical order. We run SoloLuck, and it is checked by the same probe, with the same rule and on the same page template as every other pool. SoloLuck has not found a Bitcoin block.

Where a pool runs several ports on one server, we check one of them, plus its TLS port where it has one. What these pages do not measure: fees, payouts, hashrate, blocks found, how fast a pool sends new work, or whether your miner is set up correctly.

Stopping these checks

If you run a pool and would rather we did not check it, add these two lines to the robots.txt served over HTTPS on the pool's website, on the stratum host name or a parent domain:

User-agent: SoloLuckLatency
Disallow: /

The probe reads robots.txt before it connects, keeps each answer for up to 12 hours, and skips the pool within 24 hours, with no request to us needed. We stop showing its readings, and a pool with every endpoint opted out is removed from these pages, its own page included. You can also tell us through the contact page.

Times

Every time on these pages is UTC and is the time a check was made. Pages update when new checks arrive; the page you have open fetches itself again every two minutes while it is on screen. Method last changed 2026-09-18.