HashRadar
Pools
Real YieldIndex
CoinsASICUptime
BlogChartsBlocksGlossaryAPI

Product

  • Pools
  • Charts
  • Blocks
  • Profitability
  • Hashprice Index
  • Coins
  • Miners
  • Uptime

Rankings

  • Best FPPS Pools
  • Best PPLNS Pools
  • Lowest Fee Pools
  • Lowest Payout
  • Most Profitable
  • Best for Beginners
  • Best for S21

Resources

  • Blog
  • Glossary
  • API Docs

Legal

  • About
  • Privacy
  • Terms
HashRadar© 2026 HashRadar. All rights reserved.Data: mempool.space, CoinGecko

Pool Uptime Monitor

Independent monitoring of Bitcoin mining pool availability. Stratum, website, and dashboard endpoints checked every 5 minutes from a single location (Contabo VPS, Germany).

All pools operational
Pool Uptime Status
PoolStatusStratumWeb90-Day History
Operational
100.00%
473 ms
Operational
100.00%
218 ms
Operational
100.00%
168 ms
Operational
100.00%
279 ms
Operational
100.00%
356 ms
Operational
100.00%
654 ms
Operational
100.00%
269 ms
Operational
100.00%
741 ms
Operational
99.90%
160 ms
Operational
99.90%
374 ms
Operational
99.88%
530 ms
Operational
99.87%
1141 ms
Operational
99.79%
441 ms
Operational
99.77%
184 ms
Operational
99.77%
693 ms
Operational
99.62%
221 ms
Operational
99.46%
156 ms
Operational
99.46%
226 ms
Operational
99.24%
335 ms

Recent Incidents

No incidents recorded

Why Pool Uptime Matters

When a mining pool goes down, your ASIC hardware continues consuming electricity but earns nothing. Even brief outages can cost miners significant revenue, especially at scale. Independent uptime monitoring helps you identify the most reliable pools and avoid those with recurring availability issues.

How We Monitor

HashRadar checks each pool's Stratum endpoint every 5 minutes using a full mining protocol handshake: we send mining.subscribe followed by mining.authorize, just like a real miner connecting to the pool. This proves the pool is not only reachable but actively serving mining work. We also monitor HTTP endpoints (websites and dashboards) for web availability.

Incident Detection

Our incident state machine requires 3 consecutive failed checks (15 minutes) before declaring a pool down, preventing false alarms from transient network issues. Recovery requires 2 consecutive successful checks. This approach balances sensitivity with reliability, giving you accurate uptime percentages you can trust.