Uptime

Imagine a machine meeting our operating condition for 23 hours during a 24-hour period. In this example of ours, uptime is about 95.83 %. Exclude the maintenance hour from the observation period and the percentage changes, even though nothing changed on the machine. Exceptions must therefore be visible. The US National Institute of Standards and Technology (NIST) relates availability to usable access to a service or information; it does not supply one universal mining percentage. Define the service and time period first, then assess the number. [1]

Hashrate is the number of mining attempts per second. In its 2026 explanation, Braiins distinguishes Worker System Uptime from Worker Hashing Uptime. The first tracks whether the device responded; the second tracks intervals with nonzero hashrate. We may therefore reach its control page while calculations have stopped. Conversely, a little computation does not establish the manufacturer’s rated performance. The readings are useful together: one shows reachability and the other work, but neither explains the entire outcome alone. [2]

Braiins Manager uses Unknown when required data is unavailable. Agent Offline means its collecting service—the agent relaying the data—is not responding. That alone does not establish stopped mining: monitoring may fail while the device keeps working. Nor can a gap automatically be marked as successful operation. Report unknown periods separately, or explicitly explain how they enter the calculation. Otherwise the same missing measurements can leave opposite impressions on different dashboards. [3]

A Mining Pool combines miners’ work and distributes rewards under its rules. Devices do not send every attempt, but selected results meeting the pool’s easier target, called shares. Braiins Pool estimates effective hashrate from submitted results. Over short periods, randomness in finding shares and connection quality affect it. A lower pool reading cannot simply be translated into an equally large downtime percentage. First compare matching periods and check whether the pool received and accepted the work. [4]

In Braiins Pool monitoring, Offline means no hashrate was detected. The pool is not directly testing the machine’s network reachability. The documentation describes snapshots every 5 minutes; moving from OK to Low requires two consecutive periods below the configured threshold. Disabled means monitoring is off, not that mining has stopped. A red or gray label is therefore a starting point for investigation, not a finished diagnosis. A similarly named state in another tool may have a different definition. [5]

Braiins Manager dashboard documentation specifies data refreshes every 5 minutes but a 20-minute delay for time-series data, meaning measurements arranged in time order. Refresh time and the time of the displayed event are therefore different. While investigating an alarm, the last graph point may not yet reflect an intervention or the present state. Check the event time, time zone and point’s age before drawing conclusions. Those intervals belong to the cited documentation, not to every monitoring tool. [6]

Curtailment means deliberately limiting operation, for example because electricity is expensive or the power grid requests it. Braiins explains why lower hashing uptime in that situation need not indicate a technical fault. Reports should separate planned curtailment, maintenance and unexpected failures. All can reduce computation time, but each cause calls for a different decision. Higher uptime alone does not establish greater profit either: electricity prices, performance and accepted work matter, not just powered-on hours. [2]

A worker is the name under which a pool records work. Braiins Pool notes that it monitors multiple devices sharing a name together, preventing individual diagnosis from that aggregate alone. This example uses the same observation period for both machines. Each machine’s weight is its share of their combined nominal hashrate. Consider our example of machines rated at 100 TH/s and 200 TH/s—trillions of attempts per second—with uptime of 100 % and 50 %. The simple average is 75 %, but weighting by nominal hashrate gives 66.67 %. The stronger machine’s downtime carries more weight. This average still does not measure accepted shares; it summarizes operating time differently. Always disclose the weights used. [5]