Comment on GitHub Outages Since Microslop Acquisition
Obi@sopuli.xyz 4 weeks agoThis 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.
Tiresia@slrpnk.net 8 hours ago
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.