This is a commonly known issue with graphs and one that gets repeated without a lot of consideration for context. While it’s generally a good basic rule to have graphs show the full vertical axis, it’s not like it’s a hard rule that needs to be followed 100% of the time. In this case for example, moving from 99.999% (five nines) to 99% (two nines) is a significant effect, it has importance. Displaying the full axis would make that difference unnoticeable and render the graph useless.
The difference between 97.1% uptime and 97.2% uptime is far less important than the difference between 99.98% uptime and 99.99% uptime, even though this graph shows the former as 10 times larger.
You are right to complain that a graph that exaggerates uptime differences on the scale of 10%, i.e. showing the full linear range from 0% to 100%, would be useless. But by the same token, a graph that exaggerates uptime differences on the scale of 1%, i.e. the OOP, is also useless. That we happen to live in a world where github’s uptime is varying at the scale of 1% doesn’t make the scale any more useful.
In this case, the graph of -log(1-uptime) would get you the “number of nines”, which is commonly used because it’s more insightful and more indicative of actual quality. Better still would be log(uptime(t)/(1-uptime(t)), which is functionally the same above two “nines”, but also allows the plotting of low uptime services, such as individual seeders for torrents or specific nodes of a mesh, on the negative part of the scale.
Yes I absolutely agree but it has to be transparent and for me it is intentionally misleading to show it like this. Yes, it’s still significant and still shows lack of care from microslop but context matters to me. Maybe more than to others :)) I acknowledge that I am special that way and this is fine for others
This is a commonly known issue with graphs and one that gets repeated without a lot of consideration for context. While it’s generally a good basic rule to have graphs show the full vertical axis, it’s not like it’s a hard rule that needs to be followed 100% of the time. In this case for example, moving from 99.999% (five nines) to 99% (two nines) is a significant effect, it has importance. Displaying the full axis would make that difference unnoticeable and render the graph useless.
The difference between 97.1% uptime and 97.2% uptime is far less important than the difference between 99.98% uptime and 99.99% uptime, even though this graph shows the former as 10 times larger.
You are right to complain that a graph that exaggerates uptime differences on the scale of 10%, i.e. showing the full linear range from 0% to 100%, would be useless. But by the same token, a graph that exaggerates uptime differences on the scale of 1%, i.e. the OOP, is also useless. That we happen to live in a world where github’s uptime is varying at the scale of 1% doesn’t make the scale any more useful.
In this case, the graph of
-log(1-uptime)would get you the “number of nines”, which is commonly used because it’s more insightful and more indicative of actual quality. Better still would belog(uptime(t)/(1-uptime(t)), which is functionally the same above two “nines”, but also allows the plotting of low uptime services, such as individual seeders for torrents or specific nodes of a mesh, on the negative part of the scale.Yes I absolutely agree but it has to be transparent and for me it is intentionally misleading to show it like this. Yes, it’s still significant and still shows lack of care from microslop but context matters to me. Maybe more than to others :)) I acknowledge that I am special that way and this is fine for others