Hosting puts your Bitcoin miner in someone else’s building. Monitoring is the mechanism that keeps it yours.

When your Bitcoin miner sits in a facility on another continent, monitoring is the only thing standing between ownership and trust. It is what turns a machine you cannot touch into an asset you can verify. And it is the area where hosting providers differ most quietly, because a monthly PDF summary and a live per-machine dashboard both get described with the same word.

The distinction that matters is between seeing and doing. A dashboard shows you that something is wrong. A control room lets you act on it – restart the machine, pause it, change the pool, raise a repair request – without waiting on anyone. This guide sets out the four things you should always be able to see, why per-miner reporting beats account averages, what automation should handle while you sleep, and a weekly routine that takes about five minutes.

Key takeaways

• You should be able to answer four questions without contacting anyone: is it running, how fast, how hot, and how much of the month has it been on.
• Insist on per-miner reporting. An account average hides the single machine that has been dark for a week.
• Seeing is not enough – you should be able to restart, pause and change pool settings yourself, from the same screen.
• Automation should act before you do: monitoring that detects a stopped miner and restarts it without a ticket.
• Uptime and status in the OneMiners app are reported per miner, on iOS and Android, across 20 sites and about 2,163 MW.
• Five minutes a week is enough: status, uptime, temperature trend, hashrate versus rated speed, pool, and energy balance.

The four things you should always be able to see

Good monitoring answers four questions on demand, without an email and without waiting for a monthly report. If any of the four requires contacting the host, the monitoring is a reporting service rather than a monitoring system.

• Is my Bitcoin miner running right now? A live status, per machine, not a site summary.
• How fast is it working? Current hashrate, so you can compare it against the model’s rated speed.
• How hot is it? Temperature, and ideally the trend rather than a single reading.
• How much of this period has it actually been on? Uptime for your machine, over a window you choose.

The fourth is the one people forget to ask for, and the one that matters most financially. Uptime is what you are paying a host to deliver, so it is the number that should be hardest to obscure and easiest for you to read. If a provider can show you live status but not your own historical uptime, they are showing you the easy half.

Why hashrate and temperature matter as much as status

A machine can be online and still underperforming, which is why a single availability figure is an incomplete picture. Thermal throttling is the common case: the hardware protects itself by slowing down, so it reports as up while producing materially less work.

This is why the hashrate-versus-rated-speed comparison is worth a glance each week. If an Antminer S23 Hyd 3U rated at 1.16 PH/s is delivering meaningfully less than that consistently, something is wrong – a weak board, a cooling problem, or a firmware issue – and none of it will appear in an uptime percentage.

Temperature is the leading indicator. Heat trends upward before hardware fails, so a rising trend over two or three weeks is a reason to raise a ticket while the machine is still working, rather than after it stops. Read the direction, not the number.

Per miner, not per account

Ask any prospective host one question: are these figures per machine, or averaged across my account? The answer changes what the numbers mean entirely.

Consider a five-machine fleet where one unit has been offline for a full week. Per-machine reporting shows one miner at roughly 75% for the month and four near 100% – and you act on it the same day. An account average shows about 95%, which looks like a normal month against a 95% floor. Same reality, and only one version of it lets you do anything.

OneMiners reports uptime and status per miner for exactly this reason. It is also the standard we would tell you to hold any host to, including us: the level at which you can act is the level at which the data should be published.

Putting numbers on a throttled machine

Throttling is the failure nobody notices, because the machine stays online the whole time. It is worth doing the arithmetic once so you know what you are looking for.

Take an Antminer S23 Hyd 3U, rated at 1.16 PH/s. If heat holds it at 90% of rated speed, you are losing 116 TH/s continuously – the equivalent of switching off a 200 TH/s Antminer S21 for more than half of every day, permanently. Uptime for that machine still reports as 100%, because it never stopped.

Now compare that with a genuine outage. A full day offline costs 1/365th of the year, about 0.27%. A 10% throttle sustained for a month costs about 0.83% of the year in output – three times as much, with no alert, no ticket and no entry in any downtime report.

That is the entire reason to read hashrate alongside uptime. Availability catches the loud failures. The comparison against rated speed catches the quiet ones, and the quiet ones tend to run for longer precisely because nothing draws attention to them.

What monitoring cannot tell you

Being clear about the limits is as useful as listing the features, because it tells you which questions still need a human.

• Why a machine stopped. You see that it stopped; the cause needs someone at the facility.
• Whether a part is degrading. Temperature trends hint at it, but nothing predicts a power supply failure reliably.
• What is happening at the site – a grid event, a maintenance window, weather. That comes from host communication, not telemetry.
• Whether your rate or terms changed. Contract facts do not appear in a dashboard.
• Pool-side problems. If the pool is having difficulties, your miner looks perfectly healthy while producing nothing useful.

The practical implication: judge a host on how they communicate the things monitoring cannot show, as well as on the quality of the app. Proactive notice of a maintenance window is worth as much as a live dashboard, and it is a much better indicator of how the relationship will run.

What automation should handle while you sleep

You are not the monitoring system. The facility is. Your app should be a way to verify what the facility already did, not a night shift you signed up for without realising.

At our sites, monitoring detects a stopped machine and attempts an automatic restart before any human is involved. A large share of stoppages clear at that step, in minutes, with no ticket and no action from you. AI Smart Mining tunes how the fleet runs on top of that, with a stated revenue effect of 6-115% depending on conditions.

The practical test is simple. Ask a host: if my miner stops at 3am, what happens next, and who does it? If the honest answer involves you noticing in the morning, the monitoring is a notification service. If it involves automated detection and restart, the monitoring is doing its job.

A five-minute weekly routine

Monitoring hosted hardware should not consume your week. A short, consistent routine catches almost everything that matters, and consistency beats intensity here – a five-minute check every week finds problems that an hour-long deep dive once a quarter will miss entirely.

• Confirm every miner is online – weekly. Catches a silent failure within days.
• Read uptime per miner – weekly. This is the number you are paying for.
• Check the temperature trend, not one reading – weekly. Heat rises before faults arrive.
• Compare hashrate to rated speed – weekly. A persistent gap means throttling or a weak board.
• Verify pool and payout address – monthly. Confirms nothing changed without your knowledge.
• Check invoices and the energy balance – monthly. An empty balance can pause a machine.

That last item is the one that most often costs real time, and it is entirely self-inflicted. A machine paused for an unpaid energy balance is downtime no SLA covers, because the host did nothing wrong. Keep a buffer rather than paying at the last moment.

Our verdict

Monitoring is how hosted mining stays ownership rather than trust. The standard to hold any provider to is specific: per-miner data, live and self-serve, covering status, hashrate, temperature and uptime, with the ability to restart, pause and raise a repair request from the same place you read the numbers.

If a provider offers all of that, the rest of the relationship becomes verifiable rather than promised – and you can check any claim they make without asking them. If they do not, you are not monitoring your operation. You are receiving reports about it.

Frequently asked questions

Can I monitor a hosted Bitcoin miner from my phone?

Yes. The OneMiners app runs on iOS and Android and reports status, hashrate, temperature and uptime per miner, with remote control for restart, pause and pool settings.

Can I restart my hosted miner myself?

Yes. Remote control is part of the app rather than a support request. Automated monitoring also attempts a restart on its own when a machine stops, usually before you would notice.

Will I see each machine separately or just a total?

Per miner. This matters: an account average can look healthy while one specific machine has been offline for a week, which is exactly the failure you need to catch.

How often should I check my hosted miners?

About five minutes weekly for status, uptime, temperature trend and hashrate, plus a monthly check of pool settings and your energy balance. Consistency finds more than occasional deep dives.

What should I do if the app shows something I do not understand?

Raise a support request from within the app and include what you saw. Screenshots help the on-site team act faster, since they can match your reading against their own telemetry.

See status, hashrate, temperature and uptime per miner – and restart or pause any machine yourself, from iOS or Android.

Informational only, not financial advice. App features, monitoring capabilities and service terms change – verify current functionality on the linked pages before committing.