Can We Stop With the Uptime Percentages?

Jason Gorman's article "The Wall Confronting Reliable Coding Agent Autonomy" highlights the challenges of moving from 90% to 99% reliability, and from 99% to 99.9% reliability. This rang true for me, as I've experienced an increasing amount of "downtime" in my everyday work. Services like GitHub, CI, AI, and Slack have been down, and downtime seems to be commonplace.

When I visit service status pages, I'm confronted with a wall of colors and numbers like 100%, 99.72%, 99.09%, and 98.98%. At first glance, these percentages don't seem too different or alarming. They all seem like decent grades in school.

However, upon reflection, I realize that these numbers are more akin to earthquake measurements. The difference between a 6.2 and a 7.8 might not seem significant, but it represents a massive difference in magnitude. Uptime percentages have a similar issue: 99.9% and 99.99% look almost identical, but the latter is ten times less likely to occur.

Infrastructure professionals are familiar with this concept. They even have a shorthand for it: two nines, three nines, four nines. They intuitively understand the difference because they are immersed in these numbers daily. Yet, the audience for status pages is not only infrastructure professionals anymore; it's increasingly everyone.

While the math behind uptime percentages is simple, they are an inadequate interface for people who don't deeply understand the best ways to measure infrastructure reliability in a standardized, reliable, and compliant manner. Service status pages serve as the public interface for comprehending the reliability of a service. Why not simply ask: "Hey, how much downtime have you had lately?

Seems like quite a bit..."? Therefore, how about ditching the confusing percentages and instead say, for example, "GitHub Actions: 12 hours affected in the last 30 days (98.31% uptime)." This way, you require an understanding of the nonlinear significance of numbers near 100%, while the other method requires knowing what an hour is.