ASIC Fleet Dashboards: Data, Alerts and Security

An ASIC fleet management dashboard should shorten the time between a real fault and a safe response. It must join stable device identity with pool-accepted work, power, temperature, board health, network status, repair state and ownership.

A colourful summary is not enough if stale data appears current, one worker represents several machines, alerts repeat without action or remote controls have excessive privilege. This guide defines the minimum data model, alert logic, access controls and acceptance tests for a dashboard. It does not compare commercial fleet platforms.

This is covered in a separate software-selection article.

Define what the dashboard must help people decide

Start with operational questions: which machine stopped producing accepted work. This site is losing capacity, whether a thermal condition is local or site-wide, and who must respond. Every widget should support one of those decisions.

Foreman’s current documentation separates fleet dashboards, site-level collector or Pickaxe status and individual-miner diagnostics. That is a useful architectural distinction because a failed collector must not be misreported as every miner failing simultaneously.

Define dashboard users before selecting data. An owner, technician, hosting client and finance reviewer need different views and permissions. Avoid exposing wallet, network or customer identifiers merely because the monitoring product can display them.

Write the intended outcome before looking at a headline hashrate. A learning device, a useful room heater, a quiet home miner and a commercially productive machine are different purchases. The correct comparison changes when the available circuit, sound limit, heat demand, pool route or expected ownership period changes.

Use a dated decision sheet and keep manufacturer claims separate from measured results. Record the exact model, variant, power supply, firmware and operating mode. Similar product names do not make accessories, voltage, firmware or thermal limits interchangeable.

Build a trustworthy miner and data model

Create an asset register with site, rack, position, serial, model, firmware, pool worker, owner and lifecycle state. A control-board replacement can change a network identity without changing beneficial ownership. So record both physical and logical identifiers.

Collect local hashrate, board count, chip or hardware errors, fan state, inlet or board temperatures, uptime and restart reason. Pair that with pool shares, rejected work, last accepted share and worker status. Local values alone do not prove useful work reached the pool.

Record collection time, source and freshness for every metric. A dashboard must make stale or missing data visibly different from a healthy zero. The collector, database and alert service also need their own health checks.

Prefer the manufacturer specification, manual and firmware portal for identity and limits. But treat them as the starting point rather than a promise of site performance. Keep a copy of the pages and files used because support pages, downloads and product revisions can change.

Ask the seller for a serial photograph, condition statement, included accessories and a recent operating record for the actual unit. A generic product image cannot prove board revision, power supply condition, repair history or whether the miner reaches stable accepted work.

Design the network and permission boundary

Place on-site collectors and miner interfaces on a managed network segment. Allow only the destinations and protocols needed for telemetry or approved control, and do not expose miner web interfaces to the public internet.

Use individual accounts, strong authentication and the least privilege required. Separate view, acknowledge, restart, pool-change, firmware and administrative permissions. High-impact commands should require a named user and an auditable reason.

Encrypt remote management traffic where the product supports it and protect API keys as credentials. Establish how access is removed when a customer, employee or supplier relationship ends.

A competent person should confirm the electrical route for the real continuous load. Check voltage, protective device, earthing, cable, connector, socket, isolation and ventilation together. Do not assume that a plug physically fitting a socket proves that the circuit is suitable for sustained operation.

Place the miner on a trusted network segment with no unnecessary inbound exposure. Change supplied credentials, use a documented wallet and pool account, set approved backup endpoints and confirm that every endpoint belongs to the intended operator before power is applied.

Create actionable metrics and alerts

Define expected hashrate and temperature by exact model and operating mode. Alert after a sustained breach rather than a single noisy sample, then send a recovery event when the condition clears. Foreman’s current alert guidance uses time windows for offline and low-hashrate conditions to reduce noise.

Measure dashboard quality through detection time, acknowledgement time, repair time, false alerts and missed incidents. An alert that reaches nobody, cannot be assigned or has no runbook does not reduce downtime.

Reconcile fleet accepted hashrate with pool and billing records on a fixed schedule. Keep revenue and energy calculations dated, because price, difficulty, fees and tariffs change even when the physical dashboard is stable.

Measure power at the wall and compare local hashrate with accepted pool work over a representative period. Local display figures can look healthy while stale shares, invalid work, reconnects or a wrong payout address reduce useful output.

Calculate revenue and cost over a range, not one favourable day. Include electricity, pool fees, auxiliary cooling, maintenance, downtime, conversion costs and hardware value. For a heat-use case, credit only heat that replaces a cost the owner would otherwise incur.

Control dashboard and automation risk

Rank each risk by consequence and by the practical ability to detect it before purchase. A low-priced machine with uncertain firmware, exhausted cooling or a weak algorithm market can require more working capital and attention than a newer unit with a higher invoice price.

Set written stop conditions. Examples include an unsafe supply, unavailable official firmware, rejected work above the approved limit, repeated thermal shutdown, no lawful payout route or an energy break-even price below the contracted rate. A stop condition prevents sunk cost from becoming the reason to continue.

Test faults, recovery and fallback

Pilot one site and deliberately create safe test conditions: stop one worker, disconnect one collector, change a test threshold and restore the device. Confirm that the right state, alert, owner, timestamp and recovery appear without affecting unrelated miners.

Export a baseline dashboard, user list, alert catalogue and recovery procedure. Test that a technician can still identify and safely isolate a miner when the central dashboard is unavailable.

Begin with one unit or the smallest sensible batch. Photograph labels and connections, export the original configuration, note ambient conditions and record the start time. Watch the kernel or system log, board detection, fan behaviour, temperatures, local hashrate, pool connection and accepted work.

Do not declare acceptance from a short dashboard snapshot. Run long enough to expose heat soak, intermittent network faults and pool variance. Retain the test record with the invoice, serial number, firmware file and any seller correspondence so a later repair or warranty question has a clear baseline.

ASIC fleet dashboard acceptance checklist

• Confirm the exact model, variant, condition and included power equipment.
• Verify official specifications, instructions and the correct firmware route.
• Approve the continuous electrical load, airflow, heat and sound plan.
• Test network isolation, credentials, pool endpoints and payout ownership.
• Compare wall power with accepted work over a representative run.
• Model downside revenue, electricity, downtime, maintenance and resale.
• Record acceptance limits and a safe stop or return route.
• Reassess whenever firmware, network economics or site conditions change.

The checklist is deliberately evidence based. Marketing language such as home friendly, efficient or profitable has no fixed meaning without a measured operating mode and a real site boundary. The record should make it possible for another competent person to reproduce the decision.

Key points to remember

A useful ASIC fleet dashboard is an operational control, not a wall of charts. Give every device a stable identity, distinguish local and pool evidence, display freshness, tune alerts around action and keep remote privilege narrow. Prove the design with simulated miner, collector and communications failures before relying on it for customer reporting or automated action.

Next steps

Use The Mining Shop UK tools and support pages to compare the exact hardware against your real electricity, installation, pool and operating constraints before ordering or commissioning it.