Site Uptime & Utilization Summary — trailing 7 / 30 / 90 days

Regenerated 2026-08-24, ~21:00–21:40 UTC (uptime% and utilization% were computed ~40 minutes apart on the same 90-day pull; immaterial at this timescale). 13 sites, 46 pods, verified against master_config.json. Each period cell below shows two distinct numbers — they answer different questions and should not be read as the same thing:

Uptime % (top badge): fraction of 15-minute windows in the period where the site's pods, summed, hashed ≥1 TH/s — a binary up/down measure, same method as the operators' site_uptime.py / site_downtime.py.
Utilization % (line below, "Avg / Spec"): the site's measured average hashrate over the same period, as a percentage of its installed capacity (Spec). This is new in this update. A site can be at 100% uptime and still show low utilization — that's normal, not a fault: auto-sleep during high-price hours, curtailment, and thermal derates all pull the average below spec while the site stays "up." Uptime tells you whether a site is alive; utilization tells you how much of its installed capacity is actually being used, on average, over the period.

✓ Uptime good ≥95% ! Warning 85–94.9% ▲ Serious 70–84.9% ✗ Critical <70% – N/A — buildout site or data gap, see notes Util% (gray line) is not status-colored — low utilization is often expected behavior, not an alarm

Spec = actual installed miners (inv_miner_count, fallback miner_count) × 180 TH/s (M60 spec). Order as reported; not sorted.
Site	Pods	Spec (TH/s)	7-Day	30-Day	90-Day	Notes

Method & definitions

Spec (TH/s): each site's installed miner count (Google-Sheets inventory sync, inv_miner_count in master_config.json; falls back to the design figure miner_count for the few pods with no inventory sync yet: John, Dan, West TX TBD) × 180 TH/s (the M60 spec hashrate in master_config.json's misc.miner_types; this fleet runs M60s exclusively).

Uptime %: InfluxDB MARAGON_Hashrate, all of a site's pods summed per 15-minute window; a window counts "up" if summed hashrate ≥1 TH/s. Uptime % = up-windows ÷ total calendar windows in the period.

Avg / Util%: the same 15-minute MARAGON_Hashrate series, averaged (not thresholded) across all windows in the period, including sleeping miners at 0 TH/s — a true site average, not an average of only-hashing miners. Util% = that average ÷ Spec. Computed in one 90-day per-pod pull (302,225+ points), sliced into the three trailing windows in Python rather than three separate Influx queries.

* 7-day 100% figures: zero recorded down-windows in the trailing 7 days — a clean week, not a guarantee of no future downtime.

Flags & data-quality notes

Ellyson inventory gap: Ellyson 2 is configured for 185 miners (miner_count) but only 84 are actually installed (inv_miner_count) — 101 short of design, unrelated to the 2026-08-15 emergency-sleep flag recorded on Ellyson 1. Spec above already uses the corrected installed count (48,420 TH/s site-wide, not the 66,600 TH/s design figure); the discrepancy is a Google-Sheets inventory question for an operator, not a report artifact.

† WW data gap: WW's Influx history only starts 2026-07-30 11:15 UTC (≈25 days of real data). Its 30-day and 90-day uptime figures count every window before that start as "down" — a coverage artifact, not a measured outage. Its 30/90-day utilization figures are computed only over the windows that have data (2,438 of the possible 2,879 / 8,639), so they are NOT diluted by the missing period the same way — they reflect WW's actual average output over the ~25 days it has existed, which is why WW's uptime and utilization tell different stories here: uptime looks like it collapsed at 30/90d, utilization looks roughly flat with the 7-day figure. Shown as N/A (dagger) on the uptime side rather than a colored status to avoid implying a ~18% uptime crisis that isn't real.

Osprey (8 pods): reports continuously across the full 90 days at a genuine, measured 0 TH/s — the pods are live and instrumented, they're just not hashing. A non-producing buildout site with no load commissioned yet, so both uptime and utilization are a real 0%, not a gap.

West TX TBD (7 pods): a different situation from Osprey — its pods have zero data points anywhere in the 90-day window. Their last recorded write was 2026-05-07, over two weeks before this window even starts. This is a dark/unmonitored buildout site, not a measured-zero one. Both are shown as N/A since neither reflects an outage on a producing site.

Flagged in notes: Nate's 90-day uptime (52.0%) is a clear downward trend across the three windows, and its utilization falls even faster (72.7% → 56.3% → 36.8%) — when it's up, it's also running a shrinking share of its own capacity. Dan is the weakest consistently-live site on both measures at every window (65–73% uptime, 42–52% utilization) rather than a one-off dip. Stout's 90-day utilization (45.8%) is notably worse than its 90-day uptime (91.8%) would suggest — it's up most of the time but running well under capacity when it is; worth a look at whether that's curtailment/sleep policy or a partial-capacity issue.