Site Hashrate & Uptime — trailing 7 / 30 / 90 days

Sources: rated hashrate from master_config.json miner counts × M60 spec (180 TH/s/unit); measured hashrate and uptime from InfluxDB MARAGON_Hashrate, 15-min resolution (same method as /status/site_uptime.py). Window ends 2026-08-24 ~19:00 UTC.

Rated capacity vs. measured 7-day average hashrate

Uptime %, 7 / 30 / 90 day

Sorted by 90-day uptime, worst first
SitePods Hashrate specAvg 7d hashrateUtil % 7d %7d down30d %30d down90d %90d down
Hashrate spec: sum of each site's miner_count (master_config.json) × 180 TH/s, the M60 spec_hashrate from misc.miner_types. Every site in this fleet runs M60s exclusively. This is nameplate capacity, not a target — sleeping miners for auto-sleep/curtailment reasons are expected and pull the 7-day average below spec even on a healthy site.

Avg 7d hashrate: InfluxDB MARAGON_Hashrate, all pods at the site summed per 15-min window (mean within window), then averaged across the trailing 7 days. Includes sleeping miners at 0 TH/s, so it is a true site average, not an average of only-hashing miners.

Uptime method: for each site, every pod's hashrate is pulled from InfluxDB, binned into 15-minute windows (max within window), and the site is counted "up" in a window if any of its pods reported ≥1 TH/s. Uptime % = up-windows ÷ total calendar windows in the period. This mirrors the operators' own site_uptime.py (zero-hash + data-gap based downtime).

Caveats: Osprey (8 pods) and West TX TBD (7 pods) show 0% uptime and 0 avg hashrate at every window — these are non-producing buildout sites with no hashrate yet, not an outage; their "spec" column is nameplate for installed miners that aren't yet mining. WW's Influx history only goes back to 2026-07-30, so its 30d and 90d uptime and util figures partly reflect missing history rather than true downtime — over the ~25 days WW actually has data, its uptime is ~63%, better than the raw 90d figure of 17.8% suggests.