Minerstat Setup Guide: Monitoring and Management

Minerstat is a remote management and monitoring platform that has long served both GPU and ASIC operators. For ASIC fleets it offers a hosted dashboard, profit-switching data, and a worker-based view that scales from a couple of units to hundreds. A clean Minerstat setup gives an operator one place to watch hashrate, fire alerts on faults, and push pool changes without touching each miner’s web interface. This guide covers account structure, adding ASIC workers, building configuration profiles, the trigger system, and how Minerstat compares to local and cloud alternatives. It assumes familiarity with stratum URLs and miner IP addressing.

What Minerstat offers ASIC operators

Minerstat connects to ASIC miners through their native API and presents each as a “worker” on the dashboard. It reports hashrate, temperature, fan speed, pool status, and uptime, and lets an operator reboot, reconfigure, or apply a saved profile in bulk. The platform also publishes its own profitability and hardware data — useful reference material for sizing decisions even apart from the management features.

For ASICs specifically, Minerstat supports the major families: Antminer, Avalon, Whatsminer, and Goldshell among them. Access is browser-based with optional API tokens for scripting. The platform sits in the same category as several alternatives; the remote monitoring stack overview places it against the others so operators can match a tool to their scale.

Account structure and adding ASIC workers

Minerstat organizes everything under a worker group. Create the group first, then add ASIC workers either by network discovery from a local node or by manual entry of each miner’s IP and type. For pure-ASIC monitoring, the simplest path is to add each miner directly by IP and let Minerstat poll its API.

Give every worker a descriptive name that encodes location — site, rack, position — so the dashboard reads as a map rather than a list of model numbers. Assign each miner a stable IP through a DHCP reservation or static configuration; the addressing discipline in the static IP and firewall guide keeps worker references from breaking after a power cut. Confirm the polling node can route to every miner subnet before expecting data to appear.

Tags and grouping

Tag workers by model and by coin. Tags let an operator apply an action to “all S21 XP” or “all Scrypt units” without selecting machines one by one, and they keep a bulk pool change from accidentally repointing the wrong algorithm. In a mixed catalog — Bitmain SHA-256 units beside Fluminer Scrypt machines — tag by algorithm at minimum.

Tags compound in usefulness as the fleet grows. A worker can carry several tags at once — its model, its algorithm, its physical location — and an action can target any of them. That flexibility means a single fleet can be sliced different ways for different jobs: by location for a circuit-level reboot, by model for a firmware-specific setting, by algorithm for a pool change. Plan the tag taxonomy early, because retrofitting tags onto a hundred existing workers is far more tedious than applying them at onboarding.

Building configuration profiles

A Minerstat profile bundles a pool, a worker-name template, and any miner settings into a reusable unit. Define a profile once and assign it to a worker or a tag group, and Minerstat pushes the configuration. This is the core of bulk management: change the pool in the profile and every worker on it updates.

Always include a backup pool in the profile so a stratum outage fails over rather than idling the fleet. The ordering and reconnect behavior match the pool failover configuration guide. Choose a primary pool endpoint near the farm to hold down stale shares; the latency and worker URL guide explains how endpoint distance translates into rejected work.

The trigger system: alerts and automation

Minerstat’s triggers are condition-action rules. A trigger watches a metric — hashrate below a floor, temperature above a ceiling, a worker offline for a set duration — and fires an action: send a notification, reboot the miner, or run a profile. Route notifications to email, Telegram, Discord, or a webhook.

Set hashrate triggers as a percentage of each model’s rated output rather than a flat number, so the same rule works across a mixed fleet. Put temperature triggers below the firmware’s own throttle point so the alert arrives before the miner derates. As with any platform, an automatic-reboot trigger should be capped and alerted on, because a reboot loop on a dead hashboard hides the real fault instead of fixing it.

Profit switching — context, not autopilot

Minerstat publishes profit-switching data and can switch GPU rigs between coins. For ASICs the practical scope is narrower, since an SHA-256 unit only mines SHA-256 coins. Where switching applies — for instance among SHA-256 pools or coins an ASIC can serve — treat the suggested switch as input, not a command, and weigh payout scheme and pool reliability alongside the headline number. The trade-offs between payout models are covered in the FPPS versus PPLNS decision guide.

Daily monitoring with the dashboard

The Minerstat dashboard aggregates total fleet hashrate, online-versus-offline counts, and per-worker detail on click. Configure the view to match the site: a temperature sort for thermal management, a pool-status column for payout questions. A quick daily check is total hashrate against the expected sum plus a scan for offline workers.

Weekly, review the trigger log. Workers that recovered on their own repeatedly point to a marginal PSU, a loose data cable, or an aging fan — patterns that belong in a maintenance plan rather than a software setting. Catching them early is the practical payoff of monitoring, and it feeds directly into uptime; the mining uptime optimization guide turns those logs into a reliability routine.

Minerstat’s historical charts make the slow problems visible in a way a live snapshot cannot. A worker whose temperature has crept up two degrees a month, or whose hashrate has drifted down a percent at a time, looks fine on any single day and obviously failing over a quarter of charted data. Building a habit of glancing at the trend, not just the current number, is what turns the platform from a status light into an early-warning system. That trend view is also the cleanest evidence for deciding when a unit has degraded enough to retire rather than repair.

The local node and the API token

Some Minerstat features route through a local node — a small piece of software running inside the farm that handles discovery and relays commands to miners that are not directly reachable from the cloud. For pure-ASIC monitoring by IP, the node is often optional, but it becomes useful when miners sit behind NAT or on a segmented network the cloud cannot reach directly. Where used, the node host must stay powered and networked, since the cloud loses local control if it goes down.

Minerstat also issues API tokens for scripting and integration. A token lets an operator pull fleet data into a custom dashboard or trigger actions from external automation, which matters for larger operations that build their own tooling on top. Treat the token as a credential — it can control the fleet — and scope or rotate it as the team changes. The addressing and reachability groundwork that makes any of this work is the same as in the mining network setup guide.

Security and account discipline

Because Minerstat is cloud-hosted, the account login is the keys to the fleet. A compromised account can reconfigure pools, reboot machines, or stop them. Use a strong unique password and enable any available second factor. For teams, give each operator their own access rather than sharing one login, so actions are attributable and access can be revoked cleanly when someone leaves.

Keep the miner-side exposure minimal too. Miners reporting to Minerstat do not need to be reachable from the public internet; the platform reaches them through the local connection or node. Leaving miner web interfaces exposed to the internet is a separate and avoidable risk, and the segmentation practices in the static IP and firewall guide close it.

Where Minerstat fits among the alternatives

Minerstat suits operators who want a hosted, browser-accessible dashboard with strong profitability data and a flexible trigger system, billed as a subscription. Operators who prefer software running on their own hardware with a one-time license lean toward the local option in the Awesome Miner setup guide. Those whose priority is curtailment and demand-response automation may prefer the platform in the Foreman management guide.

None of these monitoring layers replaces firmware-level tuning on the miner; they observe and orchestrate. Efficiency gains still come from the autotuning and power-curve work the firmware performs. The hardware underneath has to clear its power bill regardless of console — the Coin Web Mining catalog lists current-generation units with published efficiency figures to compare.

References

• Mining hardware and profitability data — Minerstat
• ASIC rated hashrate and efficiency specs — ASIC Miner Value
• Hashprice and network revenue data — Hashrate Index
• ASIC API and firmware documentation — Braiins