Earlier quoted context omitted.
> Define regularly More often than what is considered a standard 99.99% uptime SLA? (about an hour per year.) You seem to be making it out like a couple of days a year of lost [1] developer productivity is no big deal. That said, these things happen and you should probably check your workflows if you're all that blocked by GitHub being down.
> More often than what is considered a standard 99.99% uptime SLA? GitHub SLA is 99.95% and apparently exclusive to Business Cloud customers[1]. [1] https://github.com/pricing
GitHub: October 21 Incident Report
51–60 of 119 posts
Re: GitHub: October 21 Incident Report
#52I don't understand why code hosting platforms like GitHub, GitLab or BitBucket have so many issues regularly. Is there anything special about it?
> Is there anything special about it? Yup. You notice when they're down. Whereas when your self-hosted git server goes offline for a couple of hours, nobody else notices.
Re: GitHub: October 21 Incident Report
#53I saw some comments on reddit which highlighted a pretty serious problem - many orgs rely on github as a fully integrated CD platform, with everything from code hosting, to running CI hooks, to pushing to staging or prod. It seems very unwise to have essentially your whole deployment process manager in the hands of an entity which you don't only have no control over, but which has regularly been targeted in attacks b…
We use Github heavily at my work, and at past jobs as well. But at the same time it's not the ONLY way we can work. If github has an outage, our CD will shut down, but we can still run all tests locally, and we can still push to the server directly, and we can still push code between ourselves manually and review it.
Sure, it's a hiccup in our day when it goes down, but it's not like the entire company grinds to a halt. And the alternative of maintaining servers and systems to replicate all of that would take significantly more time, potentially cost more, and is probably more likely to go down.
Re: GitHub: October 21 Incident Report
#54Don't try creating a new repo, it will create part of the meta data but not allow you to see or use the repo and the repo name gets taken.
As I initialized it with a readme and an ignore file, I had to clone it. Cloning only succeeded by doing `watch git clone` and waiting a few minutes. But it worked.
Re: GitHub: October 21 Incident Report
#55> During this time, information displayed on GitHub.com is likely to appear out of date; if the new data is not presented, users will typically retry which may result in duplicated new content.
Happened to me already. Created a new branch but it kept me informing me the non-existence, retried a few times and shortly after was created with a bunch of duplicates.
Re: GitHub: October 21 Incident Report
#56I saw some comments on reddit which highlighted a pretty serious problem - many orgs rely on github as a fully integrated CD platform, with everything from code hosting, to running CI hooks, to pushing to staging or prod. It seems very unwise to have essentially your whole deployment process manager in the hands of an entity which you don't only have no control over, but which has regularly been targeted in attacks b…
It's a tradeoff, just like anything else. We use Github heavily at my work, and at past jobs as well. But at the same time it's not the ONLY way we can work. If github has an outage, our CD will shut down, but we can still run all tests locally, and we can still push to the server directly, and we can still push code between ourselves manually and review it. Sure, it's a hiccup in our day when it goes down, but it's…
Re: GitHub: October 21 Incident Report
#57Earlier quoted context omitted.
It's a tradeoff, just like anything else. We use Github heavily at my work, and at past jobs as well. But at the same time it's not the ONLY way we can work. If github has an outage, our CD will shut down, but we can still run all tests locally, and we can still push to the server directly, and we can still push code between ourselves manually and review it. Sure, it's a hiccup in our day when it goes down, but it's…
On premises git hosting with Gittea or GitLab with mirrors to GitHub seems like a smart idea going forward.
Re: GitHub: October 21 Incident Report
#58Earlier quoted context omitted.
It's a tradeoff, just like anything else. We use Github heavily at my work, and at past jobs as well. But at the same time it's not the ONLY way we can work. If github has an outage, our CD will shut down, but we can still run all tests locally, and we can still push to the server directly, and we can still push code between ourselves manually and review it. Sure, it's a hiccup in our day when it goes down, but it's…
On premises git hosting with Gittea or GitLab with mirrors to GitHub seems like a smart idea going forward.
Re: GitHub: October 21 Incident Report
#59Earlier quoted context omitted.
I see an update 7 minutes ago. >12:56 British Summer Time >The majority of restore processes have completed. We anticipate all data stores will be fully consistent within the next hour.
Every hour they promise something will be done until the next hour. I haven’t been able to work all day so far.
Re: GitHub: October 21 Incident Report
#60Earlier quoted context omitted.
Every hour they promise something will be done until the next hour. I haven’t been able to work all day so far.
Consider this a lesson on serverlessness. (We have been similarly afflicted, but their git backend seems to be up; and even further, we have rediscovered what we stopped paying attention to: that with Git, a centralized repo is just a convenience, not a requirement.)
I wonder what the total cost of this ordeal must be. Surely in the tens of millions.