That is a lot of complaining for having no suggested better alternative.
And there is your answer to the clickbait title -- we're still using markdown because there's no alternative that is so much better that it is going to dethrone the one that has all the momentum from being the first good-enough take on this that got any traction.
It has been pretty rough. Their own numbers report just a single `9` for Actions in Feb 2026 with 98% uptime. But that said -- I don't get the 90% number.
Anecdotally, it seems believable that 1 in 50 times (2%) in Feb that Actions barfed. Which is not very nice, but it wasn't at 1 in 10 times (10%).
It looks like the aggregate stats are more of a venn diagram than an average. So if 1/N services are down, the aggregate is considered down. I don't think this is an accurate way to calculate this. It should be weighted or in some way show partial outages. This belief is derived from the Google SRE book, in particular chapters 3 (embracing risk) and 4 (service level objectives)
If you're using all services, then any partial outage is essentially a full outage.
Of course, you can massage the numbers to make it look nicer in the way you described but the conservative approach is better for the customers.
If you insist, one could create this metric for selected services only to "better reflect users".
That being said, even when looking at the split uptimes, you'd have to do a very skewed weighting to achieve a number with more than one 9.
As a “customer”, I consider github down if I can’t push, but not down if I can’t update my profile photo (literally did this today, sending out my github to potential employers for the first time in a long time). This stuff is notoriously hard to define
Thinking back to when I was hosting, I think telling a customer "your web server was running fine it's just that the database was down" would not have been received well.
I mean I think it's useful. It answers the question, "what percentage of the time can I rely on every part of GitHub to work correctly?". The answer seems to be roughly 90% of the time.
Nobody cares about every part of GitHub working correctly. I mean, ok, their SREs are supposed to, but tabling the question of whether that's true: if tomorrow they announced a distributed no-op service with 100% downtime, you should not have the intuition that the overall availability of the platform is now worse.
I remember those Cyrix chips well. We had a little shop where we would assemble boxes to spec. And hey, a 486 is a 486, we reasoned. They were cheap, ran cool, and just about as fast as the others.
Proportionally, it's as if an individual who makes $60K a year gets a speeding fine of $375. It might be moderately annoying, but it's not really going to be remembered in a month.
"We went a little over the line to figure out where the line is, so, we can now guarantee you, dear shareholder, that we're extracting the absolute maximum possible value! Isn't that splendid!"
If you want to switch back and forth between "these two web things side-by-side" and "something else" over and over, then in that case it's better than two full browser windows side-by-side because they come into the foreground and vice versa as a unit.
It is a bit of a continuation of the somewhat annoying trend of integrating features into apps that should be part of the window manager (tabs, in the first place, for example). This one is extra awkward because even windows (which has spent a lot of time behind on window management) can do two things side by side as the same unit now.
Gosh, my brain just got all fuzzy going through those one after the next. Transitioning from the previous era of CGA to 16 colors was so very exciting at the time.
I had a friend in ninth grade in the late 1900s who was a talented artist. He used his skills to make beautifully expressive pixel-art hardcore pornography on the TI-82.
He crafted a few different scenes, where for each one, he set it to loop back and forth between two frames -- and the implied motion was fantastically realistic for the resolution and fps he was working with...
My own early sysadmin experience was with Ubuntu eBox and I hated it. Because none of the expected configuration files or commands you would find on Stackoverflow would work on a eBox managed server. You would do configuration through the UI or nothing.
The debugging was also impossible, because logs were not in the expected places and standard grep on log and conf files would give you nothing.
Cockpit is way better than that. Partially because of systemd, but also dbus and other relatively new APIs in the Linux plumbing layer, which finally allowed us to implement consistent and stateless management UI of a system.
reply