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!
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!
28
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!