Historical, not historic. Extremely not historic.
GitHub's Historic Uptime
121–130 of 131 posts
Re: GitHub's Historic Uptime
#122Earlier quoted context omitted.
An aggregate number like that doesn’t seem to be a reasonable measure. Should OpenAI models being unavailable in CoPilot because OpenAI has an outage be considered GitHub “downtime”?
As long as they brand it as a part of GitHub by calling it "GitHub Copilot" and integrate it into the GitHub UI, I think it's fair game.
The third-party aspect is irrelevant, but while high downtime on any product looks bad for the company and the division, I consider GitHub Copilot an entirely separate product from GitHub, and GitHub Copilot downtime doesn't interfere with my use of GitHub repos or vice versa, so I'd consider its downtime separately.
GitHub Actions, on the other hand, is frequently used in the same workflows as the base GitHub product, so it's worth considering both separately and together, much like various Azure services, whereas I see no reason at all to consider an aggregate "Microsoft" downtime metric that includes GitHub, Azure, Office 365, Xbox Live, etc.
The most useful, metric, actually, is "downtimes for the various collections of GitHub services I regularly use together", but that would obviously require effort to collect the data myself.
Re: GitHub's Historic Uptime
#123Reminder to keep local backups of everything important while the reliability of all these services continues to degrade.
Re: GitHub's Historic Uptime
#124GitHub is 100x the size today with 100x the product surface area. Pre-Microsoft GitHub was just a git host. Now, whether GitHub should have become what it is today is a fair question but to say “GitHub” is less stable today vs. 10 years ago ignores the significant changes. Also, much of these incidents are limited to products that are unreliable by nature, e.g: CoPilot depends on OpenAI and OpenAI has outages. The en…
Sites are supposed to get more reliable as they grow and have more resources to allocate specifically towards site reliability.
Re: GitHub's Historic Uptime
#125Earlier quoted context omitted.
As long as they brand it as a part of GitHub by calling it "GitHub Copilot" and integrate it into the GitHub UI, I think it's fair game.
The third-party aspect is irrelevant, but while high downtime on any product looks bad for the company and the division, I consider GitHub Copilot an entirely separate product from GitHub, and GitHub Copilot downtime doesn't interfere with my use of GitHub repos or vice versa, so I'd consider its downtime separately. GitHub Actions, on the other hand, is frequently used in the same workflows as the base GitHub produc…
My use of GitHub is like yours; I depend on Actions, but I couldn't give less of a damn about Copilot. However, Microsoft has tried to get people to adopt Copilot-heavy workflows, where Copilot plays an integral part in the pull request review process. If your process is as Microsoft pushes for -- wait for Copilot to comment, then review and resolve the stuff Copilot points out -- then Copilot being down means you can't really handle pull request, at least not in accordance with your standard process. For people who embrace Copilot in the way Microsoft wants them to, a GitHub Copilot outage has a serious impact on their GitHub experience.
Re: GitHub's Historic Uptime
#126Earlier quoted context omitted.
> If you started the y-axis at zero, you wouldn't see much of anything. That's... kind of my point. As a reliability engineer, I'm disappointed in GitHub's 99.5% availability periods, especially as they impact paying customers. On the other hand, most users are non-paying users, and a 99.5% availability for a free service seems to me to be a reasonable tradeoff relative to the potential cost of improving reliability…
> the other hand, most users are non-paying users, and a 99.5% availability for a free service seems to me to be a reasonable tradeoff relative to the potential cost of improving reliability for them. If they are using your data, you're still paying just not in cash. As a former reliability engineer, I'm trying hard to remember back when we had multiple months in a row never reaching 100% uptime, and I can't. Yes, we…
> If you're not willing to invest in something as core as your code or service works. What are you even doing?
I think Microsoft is collecting rents. :)
Re: GitHub's Historic Uptime
#127I guess "centralizing everything" to GitHub was never a good idea and called it 6 years ago. [0] Looking at this now, you might as well self host and you would still get better uptime than GitHub. [0] https://news.ycombinator.com/item?id=22867803
This has to feel a little vindicating.
Re: GitHub's Historic Uptime
#128Earlier quoted context omitted.
Github actions needs to go away. Git, in the linux mantra, is a tool written to do one job very well. Productizing it, bolting shit onto the sides of it, and making it more than it should be was/is a giant mistake. The whole "just because we could doesn't mean we should" quote applies here.
But GitHub actions is not Git?
Sorry yes, that was my point. GitHub turned git into some dysmorphic DVCS version of c++ on the web. Git is fine. Maybe 10% of people use plain git, it’d all wrapped in shitty web apps. Let git be git, and let ci/cd be ci/cd, the way Linux intended.
However, I don’t work on web apps. Maybe it’s better for the JavaScript folks. I hope to never write a line of js in my lifetime.
Re: GitHub's Historic Uptime
#129Powered by Azure™
Re: GitHub's Historic Uptime
#130FWIW if people are looking for a reason why, here's why I think it's happening: https://thenewstack.io/github-will-prioritize-migrating-to-a...
It's absolutely this. Our Azure outages correlate heavily with Github outages. It's almost a meme for us at this point.
Azure's downtime doesn't appear to be as bad as Github's.