<p>Due to the way the system operates it's actually a fairly difficult job deriving metrics of health.</p>

<ul>
<li><p>Measuring the time since last block is very tricky as a measure of health or connectivity to the network. Block times follow a poisson distribution, you might only see two blocks in a 3 hour period and that would be completely acceptable behavior (though slightly unlikely) and not at all indicative of a problem. </p>

<p>In the other direction the July 2015 incident had over 50% of the global hashrate ended up mining an invalid chain for over an hour. Normally this might eventually indicate that you had been left behind on an invalid chain and action might need to be taken, where in this situation seeing a low hashrate meant that you were on the valid side of things. </p></li>
<li><p>Comparing your block height to other websites is pretty unreliable as well, if block explorer websites were an authority on which blocks were value then during the July 2015 event the network would have broken completely. During this event many followed the completely invalid chain and displayed this information for hours or days before being patched. Block explorer services are frequently incorrect, out of date, or simply unavailable for for phone a friend assurance of the correct chain. </p></li>
<li><p>The number of nodes is tangentially related to the health of the network, this measure has high latency and is extremely easily fooled by even the most basic of attackers. If you use this as a measure of health it could be pushed way up into the stratosphere by a bored criminal with a botnet, and it would be extremely hard to detect an attack like this happening over large time span. If anything the outlook right now based on this measure would be "extremely poor", with under 5500 nodes exposing listening ports on the public internet.</p></li>
</ul>

<p>Statistical projects like <a href="http://statoshi.info/" rel="nofollow">Statoshi</a> attempt to quantify node performance and other metrics, though many require deep knowledge of the software to make any sense of and don't give much measure of the network as a whole. Simpler projects like <a href="http://213.165.91.169/" rel="nofollow">Shorenas network monitor</a> give more general statistics about operation, bandwidth, and connections to the network. The aforementioned <a href="http://getaddr.bitnodes.io/" rel="nofollow">Bitnodes</a> project has a limited reach (not all networks are crawled, the data has been inaccurate at times), but gives a general idea of the number of listening sockets available to the wider internet. </p>

<p>It's a lot harder of a task than one might imagine setting out, and no real clear answer. </p>

CC BY-SA 3.0
2015-07-11T02:37:20.923Z
2015-07-11T02:37:20.923Z
Claris
<p>What metrics can I use as indicators of the health of (a) a full bitcoin node I am running and (b) the bitcoin network as a whole.</p>

<p>Some examples I've considered: recency of last block I received on my node is a good indicator of (a) or (b) -- if a long time passes, I have an indication that either my node or the network is not in a good state.  The number of full nodes (N) participating in the network is a good measure of (b).  N is difficult to measure but the folks here are taking a good run at it: <a href="https://getaddr.bitnodes.io/" rel="nofollow">https://getaddr.bitnodes.io/</a></p>

<p>What other metrics should I look at on my nodes or on broader level across the network, to gauge the health of my nodes and the network?</p>

<network><nodes>
Metrics Correlated to "Health" of Bitcoin Node and Network
Andrew
# Metrics Correlated to "Health" of Bitcoin Node and Network

(Asked by: username_0 on 2015-07-10)

What metrics can I use as indicators of the health of (a) a full bitcoin node I am running and (b) the bitcoin network as a whole.

Some examples I've considered: recency of last block I received on my node is a good indicator of (a) or (b) -- if a long time passes, I have an indication that either my node or the network is not in a good state. The number of full nodes (N) participating in the network is a good measure of (b). N is difficult to measure but the folks here are taking a good run at it: <https://getaddr.bitnodes.io/>

What other metrics should I look at on my nodes or on broader level across the network, to gauge the health of my nodes and the network?

**Tags:** network, nodes


---

## 1 answers

### Answer by username_1 on 2015-07-11. Score: 1

Due to the way the system operates it's actually a fairly difficult job deriving metrics of health.

* Measuring the time since last block is very tricky as a measure of health or connectivity to the network. Block times follow a poisson distribution, you might only see two blocks in a 3 hour period and that would be completely acceptable behavior (though slightly unlikely) and not at all indicative of a problem.

  In the other direction the July 2015 incident had over 50% of the global hashrate ended up mining an invalid chain for over an hour. Normally this might eventually indicate that you had been left behind on an invalid chain and action might need to be taken, where in this situation seeing a low hashrate meant that you were on the valid side of things.
* Comparing your block height to other websites is pretty unreliable as well, if block explorer websites were an authority on which blocks were value then during the July 2015 event the network would have broken completely. During this event many followed the completely invalid chain and displayed this information for hours or days before being patched. Block explorer services are frequently incorrect, out of date, or simply unavailable for for phone a friend assurance of the correct chain.
* The number of nodes is tangentially related to the health of the network, this measure has high latency and is extremely easily fooled by even the most basic of attackers. If you use this as a measure of health it could be pushed way up into the stratosphere by a bored criminal with a botnet, and it would be extremely hard to detect an attack like this happening over large time span. If anything the outlook right now based on this measure would be "extremely poor", with under 5500 nodes exposing listening ports on the public internet.

Statistical projects like [Statoshi](http://statoshi.info/) attempt to quantify node performance and other metrics, though many require deep knowledge of the software to make any sense of and don't give much measure of the network as a whole. Simpler projects like [Shorenas network monitor](http://213.165.91.169/) give more general statistics about operation, bandwidth, and connections to the network. The aforementioned [Bitnodes](http://getaddr.bitnodes.io/) project has a limited reach (not all networks are crawled, the data has been inaccurate at times), but gives a general idea of the number of listening sockets available to the wider internet.

It's a lot harder of a task than one might imagine setting out, and no real clear answer.


---

