this post was submitted on 10 Sep 2026
83 points (92.8% liked)

Programming

28524 readers
821 users here now

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

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 3 years ago
MODERATORS
top 24 comments
sorted by: hot top controversial new old
[–] pHr34kY@lemmy.world 74 points 1 week ago (4 children)

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.

[–] HelloRoot@lemy.lol 51 points 1 week ago* (last edited 1 week ago) (1 children)

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.

[–] thingsiplay@lemmy.ml 8 points 1 week ago

Percentage is good to see quick changes in relation. Having exact figures would be nice too, but that is not a replacement for percentage.

[–] tyler@programming.dev 16 points 1 week ago (2 children)

That still isn’t as good as just saying the hours…

[–] marcos@lemmy.world 4 points 1 week ago

I dunno. As the article says, the people that use those numbers know what they mean.

[–] tyler@programming.dev 2 points 1 week ago

The article is about how everyone uses status pages nowadays…

[–] stickyprimer@lemmy.world 9 points 1 week ago* (last edited 1 week ago)

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.

[–] thingsiplay@lemmy.ml 2 points 1 week ago

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.

[–] cecilkorik@lemmy.ca 39 points 1 week ago (1 children)

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.

[–] jumping_redditor@sh.itjust.works 5 points 1 week ago (2 children)

a "large" number like 99.999% looks impressive, and 99.9999% is more impressive

[–] HelloRoot@lemy.lol 17 points 1 week ago

Idea: if we run two servers, we could count as 199.9998% !!! /s

[–] stickyprimer@lemmy.world 3 points 1 week ago (1 children)

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.

[–] jumping_redditor@sh.itjust.works -1 points 1 week ago (1 children)

I thing the first nines are most important (9% vs 99%)

[–] BitUnWise@programming.dev 2 points 1 week ago

The first nine would 90% then it would go straight to 0%

[–] Bishma@discuss.tchncs.de 29 points 1 week ago (1 children)

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.

[–] Endymion_Mallorn@kbin.melroy.org 29 points 1 week ago (1 children)

Because you were solving a problem and you felt effective.

[–] PattyMcB@lemmy.world 6 points 1 week ago

I miss those days

[–] panda_abyss@lemmy.ca 17 points 1 week ago (2 children)

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.

[–] Beacon@fedia.io 9 points 1 week ago (2 children)

"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

[–] samus12345@sh.itjust.works 14 points 1 week ago

So if "innumerate" and "innumerable" are both words, there must be an "illiterable," meaning "too many words to be expressed."

[–] panda_abyss@lemmy.ca 3 points 1 week ago

I was looking for that word but didn’t arrive at it

[–] whats_a_lemmy@midwest.social 5 points 1 week ago (2 children)
[–] spartanatreyu@programming.dev 5 points 1 week ago

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.

[–] staircase@programming.dev 2 points 1 week ago* (last edited 1 week ago)

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.