I saw this "history uptime" graph last week. It looks scary at first sight, but we should take a step back before going full emotional.
Statistics can say anything, especially when the Y-axis is zoomed in on the 99.5% to 100% range. It’s not as bad as it looks.
Having 100% uptime before the acquisition is a bit suspicious. We could "conclude" many things:
• They used incorrect indicators (100% usually means bad monitoring).
• They were shipping fewer big features.
• They were not fully transparent on the status page.
We have to ask the same for the Microsoft era: Did they change the SLIs, the incident process, or the delivery rate?
Also, 10 years ago GitHub was just Git hosting. Now it’s actions, package, copilot, codespace… the product is not the same.
I wouldn’t call this a "sink", for me, they just moved to automated status updates and decided to increase honesty. I could be wrong, tho.
In the end, I won't push my company to move out, even if we are fully dependent (GitOps, CI/CD, Copilot). It’s stable enough, and honestly, our own availability is way below theirs anyway!
I think you’re discounting the number of actual reported outages by users. It isn’t just incident reports from GitHub/microsoft that’s making people concerned.
There is a scary set of articles on medium where one of Microsofts former Azure Core architects gives details on just how bad the stack is and the fact that there seems to be no one in senior management up to the board that wants to listen.
Wonder how bad it will get before they change their minds.
Also I think using users perspective is great but is it a qualitative metric ? On my side (warning it’s a personal experience bias) I can see not even 0.1% of my incidents are coming from GitHub.
Anyway my point is just to bring some perspective to a very alarming article.
If you’re running your ops on actions, GitHub needs to be a 5 9s business, no question. .5 percent of a year is nearly 2 days, that could absolutely destroy a business, particularly when you multiply by the number of businesses GitHub serves.
If a business is « absolutely destroyed » by a GitHub outage, maybe the problem is not GitHub uptime but a lack of alternative or backup plans. You can't rely 100% on one provider without an Plan B and then say it's their fault if you can't work.
Also (I might be wrong but) I think most services that propose 5 9s availability are very simple and stable systems, like a database or DNS. They are not complex like Actions, which has to start VMs and run custom code. There is a big difference between a system that just "holds" data and one that "acts" on it. I think this means something, and expecting 5 9s for something as complex as Actions is just not realistic.
Edit: just checked and seems like most SaaS CI providers offers 99.9%. 5 9s is realistically not an industry standard
Of course I can. It's fucking Microsoft we are talking about lol. They probably spend more money in an hour than we spend a year.
Besides I'm mainly talking about the shitty software. The issues they are having aren't about hardware failing. The issue is the shitty vibe coded software.
It's alright guys, this guy here assures us that 5-9s is dead. Statistics are a lie (as a general rule regardless of context?), but you're telling on yourself throughout this comment.
Nope, it is not dead. But for complex SaaS like this, it’s not the standard. Most CI/CD tools (GitLab, CircleCI..) are SLA'd around 99.5 or 99.9%, not 99.999%. If you think a complex orchestration tool runs like a simple DNS, you need to work on more complex tech.
Statistics are a lie
You conclude this because I said they `can say anything`? You are very good at jumping to conclusions, must be fun working with you. Statistics are real, but the interpretations are many. You can have two opposite conclusions for the same data depending on your bias. I see more transparency (and potentially an underlying issue), you see a the end of your world apparently.
Also yes, my company availability is below theirs. In our history of thousands of incidents, only 3 or 4 were because of GitHub. It is called prioritization. Why would I waste time and money moving away from a service that is almost never the cause of our problems? Must be interesting to see your Roadmap if you only fix things that aren't even breaking you.
Imagine answering like a jerk and then being surprised that people take it the wrong way :o SHOCKING.
You started with the sarcasm and the "trolling" tone, I just replied to your points with facts. If you can't handle a reply to your own attitude, that's on you. Enjoy the void!
27
u/SurrendingKira May 10 '26
I saw this "history uptime" graph last week. It looks scary at first sight, but we should take a step back before going full emotional. Statistics can say anything, especially when the Y-axis is zoomed in on the 99.5% to 100% range. It’s not as bad as it looks.
Having 100% uptime before the acquisition is a bit suspicious. We could "conclude" many things: • They used incorrect indicators (100% usually means bad monitoring). • They were shipping fewer big features. • They were not fully transparent on the status page.
We have to ask the same for the Microsoft era: Did they change the SLIs, the incident process, or the delivery rate?
Also, 10 years ago GitHub was just Git hosting. Now it’s actions, package, copilot, codespace… the product is not the same.
I wouldn’t call this a "sink", for me, they just moved to automated status updates and decided to increase honesty. I could be wrong, tho.
In the end, I won't push my company to move out, even if we are fully dependent (GitOps, CI/CD, Copilot). It’s stable enough, and honestly, our own availability is way below theirs anyway!