More simply, replace uptime with downtime.
99% uptime and 99.9% uptime seem close.
1% downtime and 0.1% downtime is clearly a 10x difference.
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
More simply, replace uptime with downtime.
99% uptime and 99.9% uptime seem close.
1% downtime and 0.1% downtime is clearly a 10x difference.
Rather than guess at which percentage representation is more intuitive to people, the blog post suggests something more concrete:
instead of: GitHub Actions: 98.31% uptime.
We say something like: GitHub Actions: 12 hours affected in the last 30 days (98.31% uptime).
I’ve been presenting numbers to people for a long time and I know they flip back and forth between “these percentages are abstract - what’s the actual total number?” and “how do I put these totals in perspective? What percentage is it?” The blog post suggests offering both, which is the right choice.
Why not just give hours/minutes per year/month??
I have no intuitive feeling for what 0.078% is, but if it says: "average downtime of 44 minutes per month" or "7h per year" it's clear as day.
Percentage is good to see quick changes in relation. Having exact figures would be nice too, but that is not a replacement for percentage.
That still isn’t as good as just saying the hours…
The article is about how everyone uses status pages nowadays…
I dunno. As the article says, the people that use those numbers know what they mean.
Also in addition 99 is interpreted in the brain very close to 100. That's why we have prices like 99.99. Just an additional thing to your excellent reasoning about the 10x difference look.
The whole point of status pages is to minimize and deflate the impact. The pleasantly-high percentages even during absolute catastrophes is an intentional design feature. The percentages are not going anywhere. The percentages will continue until reliability improves. Which it won't.
a "large" number like 99.999% looks impressive, and 99.9999% is more impressive
Anyone who is actually responsible for the uptime of anything understands the difference between 3 nines and 4 nines and how significant it is to gain or lose a nine.
I thing the first nines are most important (9% vs 99%)
The first nine would 90% then it would go straight to 0%
Idea: if we run two servers, we could count as 199.9998% !!! /s
In my day we just committed seppuku if our uptime dropped below three-nines. I was always pushing to get my elusive 5th on a high traffic SaaS site I was lead on for many years.
I remember sitting in a Chaos Engineering conference session in Vegas (2009 or 10) while logged into 12 servers on my moto droid via tmux because someone pushed a bad patch while I was out. I just don't understand why I look back at that fondly.
Because you were solving a problem and you felt effective.
I miss those days
Also: uptime percentage must be computed as the intersection of uptime across services, not the union.
GitHub Actions: 98.31% uptime. We say something like: GitHub Actions: 12 hours affected in the last 30 days (98.31% uptime).
Normal people have no understanding of percentages or numbers, I agree saying 12 hours of downtime is more useful, but I’m also tired of trying to contextualize numbers for the numerically illiterate.
"innumerate", same as illiterate, but for numbers. Not sure if it's a common enough word for people to understand what you're talking about, but still there it is
So if "innumerate" and "innumerable" are both words, there must be an "illiterable," meaning "too many words to be expressed."
I was looking for that word but didn’t arrive at it
According to that, actions is down ~1 working day/month. That's sooooooooooo bad.
I thought big tech wanted us to move away from personal devices into the cloud. This isn't the way to do it.
Don't forget about: https://www.dayswithoutgithubincident.com/
Important because it shows their high score. The best they've done this year is 6 days without an incident. That's their high score.
They're tied for their high score right now which is cool, but it's shameful that the longest they've gone all year without something going down is 6 days.