GitHub Incident

https://www.githubstatus.com/incidents/83lq7ftk19r5

by wgjordan • 4 years ago

213 165 4 years ago

githubstatus.com

abluecloud• 4 years ago

Github broken. CircleCI broken. I'm going for a coffee.

trutannus• 4 years ago

Its the snow-day of the tech world.

relieferator• 4 years ago

went to downdetector first but this is betta

kiloreux3• 4 years ago

This is getting too much.I wonder what effects this will have on the reputation of Github. If I am blocked by Github every few days and can't properly operate. I will start looking for a more reliable alternative. And I am just a solo dev that pays $4, what happens to companies for whom time is worth a lot of money? Pretty disappointing.

chockchocschoir12• 4 years ago

How do you as a solo developer get blocked on anything related to GitHub? Are you doing all project planning on GitHub without any other copies elsewhere? Most if not everything you do on GitHub could be replicated locally, one way or another.

I can understand the problem for larger development teams, as a lot of communication and workflows can happen via GitHub Pull Requests or similar.

tyingq3• 4 years ago

Maybe using their CI/CD?

kiloreux3• 4 years ago

I am a solo dev, but I work in a company and now have been working on pushing something to test it on Github actions. If it was something different, maybe. But I understand how I might have miscommunicated that.

bilekas2• 4 years ago

Most if not everything you do on GitHub could be replicated locally, one way or another

That's not really the point though.. If you have services in github etc, why would you replicate all of them locally too for unplanned downtime ?

kayodelycaon2• 4 years ago

Personally, I can't deploy if GitHub is down. CI pulls from GitHub. One of my projects includes libraries as submodules, with GitHub as the origin. The deployment configuration has everything cloning from GitHub.

coldpie2• 4 years ago

Try building any Rust project while GitHub is down.

zthrowaway2• 4 years ago

Anyone think the warnings issued of Russia's cyber attacks has any correlation here?

fishnchips• 4 years ago

I'd personally correlate it with their Azure migration. Either that, or recent launches. Stability aside, they've been shipping a lot of changes recently. And more often than not, changes lead to outages.

zthrowaway2• 4 years ago

Yeah I could see that... with just them going to Azure alone lol. Azure was very unstable at a previous company I was at.

JonChesterfield2• 4 years ago

Seems likely that migrating to Azure is related to being acquired by Microsoft. I blame the new ownership for the decreased stability.

dgellow• 4 years ago

time_to_smile• 4 years ago

I would expect any serious Russian cyber attack would more closely resemble "polonium tea" in the sense that it would be: incredibly destructive, quite obviously from a state actor, and yet officially not connectable to Russia.

Strategically cyber attacks are the most effective when they damage your adversary heavily, and yet at the same time make it so that politically retaliation looks like aggression since there is no unquestionable link between the actor and the action.

Consider Stuxnet as an example. Widely understood to be a joint US/Israeli cyber attack on Iran, and at the same time difficult to retaliate against.

While annoying, these outages we've been seeing are hardly doing any serious harm. Very little money is ultimately lost because of them, and it's not remotely clear that this is a cyber attack. So if they were cyber attacks it wouldn't make much sense. Not saying that it's impossible they are, but it seems there are many other more plausible explainations.

eutropia• 4 years ago

As someone who is responsible for CI/CD...

welp.

I'm thankful that at least I'm not on security investigating the severity of the okta hack.

5e92cb50239222b4• 4 years ago

This has been happening pretty much every day for a long time. Maybe this will push more people towards some decentralization. A self-hosted Gitea instance my organization has been using had exactly zero downtime in the past year. None. Same with our CI system. Yes, I know, GitHub is 10⁹⁹⁹ times larger than our puny Gitea instance, and that's why they're having issues, but why should I care when one is working, and the other one isn't?

chockchocschoir12• 4 years ago

It's not about being larger, it's about doing changes. GitHub used to be pretty stable before, when they didn't really do any (user facing) changes. It stood still in terms of features, but was also pretty stable overall.

Compared to GitHub, how often does your Gitea instance go through code changes? How many major features have been switched on in that instance during the past year without any hiccups?

Deukhoofd3• 4 years ago

I run Gitea myself as well. I generally throw in a new release once a month or so, never had any real hiccups.

freedomben4• 4 years ago

I tried to look at the Gitea repo to see how fast they get commits, but github is 500ing :-(

https://github.com/go-gitea/gitea

dogleash2• 4 years ago

GitHub's feature churn is irrelevant to the comparison unless those features are used in parent poster's workflow.

newswasboring2• 4 years ago

An infrastructure company focusing on feature churn just sounds wrong.

skeeter2020• 4 years ago

> A self-hosted Gitea instance my organization has been using had exactly zero downtime in the past year. None. Same with our CI system.

And when they do go down, how long will they be unavailable? When this happens (and it will happen) please post here so we can say "why are you running infrastructure yourself?"

Nextgrid3• 4 years ago

Very likely to be lower than GitHub/etc, because it's a much simpler system that can be reinstalled from scratch in 30 minutes by an experienced admin on brand new hardware if needed.

5e92cb50239222b4• 4 years ago

Less than you've already wasted waiting for GitHub to come up from the dead in the last year alone. If you're insinuating that we'll have to restore everything from scratch, don't worry, the machine is being continuously replicated and sysadmins are trained to restore everything chop-chop.

jchw3• 4 years ago

I ran a GitLab instance for a company pretty much solo and it never wound up going down outside of when I was upgrading it, that I can recall. The thing about that is, it’s a small scale instance. If an upgrade or change failed, I could literally delete everything and restore from backup in under an hour, and never really needed to do that (although to be clear, I did actually test that it was possible.)

Now I’ll tell you the real problem with it: it worked great for people who were located in the U.S., but it was terrible for certain remote employees due to increased latency, and the fix for that would be to set up a complicated replication setup that puts data closer to people not near the main instance.

There’s obviously other issues, but that is one that is probably commonly overlooked that most SaaS solutions can do better on.

ghusto3• 4 years ago

With something as simple as serving git for your own organisation, when you do get downtime it's going to be a case of restoring from backup and changing DNS. No need for complicated infrastructure, so bringing it back really is that simple.

Worst case is losing commits between going down and backups, but even then it'll be minimal if you set your backup to simply push to a another origin.

I pay for someone else to worry about most services, but git doesn't have to be one of them.

chousuke• 4 years ago

Depends on your setup. For a simple git server on AWS I might have it on a single-node ASG so that when something terminates the instance, the ASG notices and launches a new one. The initialization scripts would then attach and mount a pre-existing EBS volume and start services.

Very simple to set up, and as long as your data volume is not lost (which can happen, but is very rare), such a system would recover from a host failure by itself faster than most people could react to it going down. In the unlikely case that you lose the EBS volume, you'd just recover from snapshots manually.

scandox2• 4 years ago

5 years of a Gogs instance. Zero downtime. I'll come back to you when it goes down.

thrashh• 4 years ago

I once worked at a place that self hosted a lot and they had fail-over, backups and restores dialed in

If something like Git went down — which it never — it was a few clicks away from coming back

Working with competent people is a blast

johnisgood• 4 years ago

Infra I have been running myself only goes down when I reboot INTENTIONALLY.

aprdm• 4 years ago

I've been running gitlab for ~5y in companies with ~200 devs and haven't had a single downtime, it also takes very little work/effort.

dijit2• 4 years ago

I'm honestly sick of this conversation.

Have we as an industry forgot how to make systems? that's pretty telling if so.

Why are people so utterly afraid of running their own systems.

If a SaaS platform goes down it's followed by "#hugops; running large systems is hard!", when someone says "Well, if it's hard, why not break it into smaller pieces and run it myself" it's met directly with "Do you think you can do better!?!".

Honestly, probably, maybe not. Why does it matter?

Those two things cannot be true simultaneously. You cannot say "running big systems is hard" and "they can run a big system better than you can run a small system".

I'm not going to fall into the trap of arguing points like the fact that if you own the data you can have your own D/R & backup strategies and the fact you can run maintenance's on your own time (hell: you can run maintenance's to migrate things around, which is more than github can do, which is not an indictment of them, just the nature of being a hosted service).

Honestly, I miss sysadmins. People who were not afraid of servers, even if they said "no" sometimes. Because, you know, being afraid of servers and hosting things is just pathetic.

manicdee• 4 years ago

It only takes one month long outage of an international undersea cable to negate all the benefit of SaaS when that SaaS is hosted in or heavily depends on other services hosted in the USA or Europe.

DNS goes down for a particular dot com? BGP hijinks? Backhoe through the major fibre serving your workplace?

All of these are going to happen and will lead to downtime out of your control or the control of the SaaS provider.

Thankfully git is designed to be decentralised and developers can continue to work even if they have to use paper books as reference material and not Stack Overflow.

contravariant• 4 years ago

10^999, really?

Rule of thumb is that 10^100 of anything doesn't fit in the observable universe.

rvz2• 4 years ago

A self-hosted Gitea instance my organization has been using had exactly zero downtime in the past year.
Yes, I know, GitHub is 10⁹⁹⁹ times larger than our puny Gitea instance, and that's why they're having issues

Exactly. That is also my overall point. [0] It makes no sense to go 'all in' on GitHub and something goes down and everyone is stuck once again.

[0] https://news.ycombinator.com/item?id=30711442

freedomben4• 4 years ago

Mind sharing some details on your install? Which database are you using (especially wondering about sqlite with gitea)? Are you using the docker install, or from package, or in k8s?

No pressure, but I'm seriously considering standing one up but it would need to be production ready.

raxxorrax2• 4 years ago

Gitea is absolutely production ready, we use an older version by now and don't even think about it much because it just works so well. Exactly what you want in production (production = software should work more often).

Actually not "vendoring" dependencies from github is very much not production ready in many cases.

qbasic_forever3• 4 years ago

IMHO storage is the big issue to figure out with a production ready gitea installation. Gitea only supports the local filesystem for storing bare repo data and not anything like S3 or other distributed or highly available storage systems (it supports S3 only for git LFS data right now, it is a long awaited open issue to get the bare repos there too).

So the big issue for any non-trivial or highly available setup is going to be how you get high availability for the local storage volume. There are tons of options with various tradeoffs and levels of complexity here--simple local disk RAID, distributed filesystems like gluster or ceph, etc. I think this is the real crux of getting a good gitea instance going.

No matter what figure out and test a good backup and recovery solution!

5e92cb50239222b4• 4 years ago

It's a really boring setup, I'm unlikely to share anything of much value here.

No k8s or anything like that. An Ubuntu LTS virtual machine on top of I don't know what hypervisor (probably Hyper-V). Gitea requires very few resources.

Data is stored in PostgreSQL 11. Probably should be upgraded at some point, but it's working fine for now.

A Drone CI instance runs on that same machine. It controls CI workers on a dozen other VMs.

Everything is in Docker containers under docker-compose for two reasons: easy upgrades, and the ability to shove all data into a single directory.

caddy for HTTPS.

Sonatype Nexus for package repositories (caching upstream npm, nuget, maven, composer, and our own internal repos). This one is pretty heavy and will probably be moved to a separate machine at some point.

Never had any issues with any of these in about three years we've been running this setup.

I was a bit facetious with the "zero downtime" statement. It has about 30 seconds of downtime per month, but it is always planned and outside of working hours deep into the night.

There's been zero seconds of unplanned downtime.

Basically you do:

    $ docker-compose pull
    $ docker-compose up -d

and half a minute later it is running new versions. If anything is broken (it hasn't been yet), call the sysadmin guy, and a few minutes later he restores a VM snapshot.

Backups are being done on the hypervisor's level. I don't know about that much.

corobo3• 4 years ago

Opposite anecdata my GitLab install absolutely self destructed itself at one point and I had to rebuild it myself, waste of a weekend

ashildr2• 4 years ago

my GitLab install absolutely self destructed itself

That’s frightening, we’ve been using it for multiple years now. It’s running fine and the only short downtime is every few weeks for the update.

What happened to your instance?

qbasic_forever3• 4 years ago

Git is distributed, you should be able to completely detach from your remote and still work effectively. I think a lot of big projects get too lazy about good, reproducible build environments and just rely on centralized CI to do everything.

gmueckl• 4 years ago

If you haven't noticed, the whole point of GitHub is to infest git-using environments with so many centralized features that user's get trapped using that service. Seems like issues and actions are doing that job nicely!

MattGaiser• 4 years ago

GitHub isn't just a repo in many cases. It is project management software.

candiddevmike• 4 years ago

Gitea is nice, what CI/CD system do you use with it? I used it in the past with Drone, and Drone left a lot to be desired (coming from/going back to GitHub actions, Drone's job syntax is a bit more complicated and focused on containers).

ncrmro• 4 years ago

I've used Drone CI in the past with Gitea. I still prefer gitlabs CI tho

5e92cb50239222b4• 4 years ago

Drone CI has been working fine for our purposes. I agree that it may not be the most feature-packed thing in the world (for example, caching support is missing completely), but there are lots of plugins and it's easy to write your own.

We've been using exec and ssh runners when containers are not enough (for example, when you need to juggle a few VMs or build some complicated Docker image, and using docker-in-docker is not fun).

https://docs.drone.io/pipeline/exec/overview/

https://docs.drone.io/pipeline/ssh/overview/

GitHub Actions are nice… when they're actually working.

ksnll• 4 years ago

Cannot really rely on Github lately. Wondering if they have some sort of post mortem for the incidents of last month. I would like to see why we should trust it to not go down again.

chockchocschoir12• 4 years ago

I would like to see why we should trust it to not go down again.

You shouldn't ever trust anything to never go down again. It's just inevitable that services go down from time to time, you can't change that unless we have a major breakthrough in software engineering where somehow people stop making mistakes.

So instead of figuring out if you should "trust it to go down again or not", assume it will at one point in the future and plan accordingly. This is how you build resilient systems.

ahmadrosid• 4 years ago

Today, I saw a beta timeline feature. Could it be this incident related to this release?

rvz2• 4 years ago

From [0]

Until the next time GitHub goes down again (hopefully that won't be in another month's time).

Oh dear. [0] Never expected it to be this soon or that bad. Expected it to be down in a few weeks at least. Last time this happened was just 5 days ago. [1]

Yet I see complaints here of GitHub being unreliable as predicted and even some considering to eventually self-host despite paying $4 a month even.

I don't think it make sense to go 'all in' on GitHub, does it?

[0] https://news.ycombinator.com/item?id=30714123

[1] https://news.ycombinator.com/item?id=30711442

duckmasterflex• 4 years ago

My boss threw his hands up and said we a switching to gitlab. I love github, why you doing this to me Microsoft!

judge20202• 4 years ago

It seems the pre-MS GitHub's approach of "we have maybe 1 new feature a year in the pursuit of keeping our duct-taped service afloat" might have been the right call. Nowadays tons of new features are pushed out every week[0].

0: https://github.blog/changelog

darknavi• 4 years ago

I get what you're saying but I cracked up at this "GitHub is releasing too many features and breaking things!" because when I clicked your link the latest entry is:

Diffing Adobe Photoshop documents is no longer supported

raxxorrax2• 4 years ago

How can a system be stable if you don't at least scrap two features a year?

EMIRELADERO• 4 years ago

It would be nice if GitHub started operating the way GitLab does. Free community edition (open-source) and paid proprietary Enterprise Edition (source-available). Developement being completely public (employees push their commits, do code review and work on issue boards on the official GitLab repo[1] which is publicly available)

[1] https://gitlab.com/gitlab-org/gitlab

mbesto5• 4 years ago

Can we please stop posting major system incidents and status pages for major cloud/SaaS providers? What's the point?

Post mortems - TOTALLY fine. But just linking to a specific incident is IMHO not valuable to HN and just takes unwarranted frontpage space.

disgruntledphd2• 4 years ago

I think it's so people realise it's not just them.

mbesto5• 4 years ago

Makes no sense. If you're having issues wouldn't you just go directly to <insert service here>'s status page first? Why HN first?

aerovistae• 4 years ago

I find this valuable.

-Sometimes for conversations about alternatives

-Sometimes for conversations about the product's stability history

-Sometimes just for solidarity in frustration

mbesto5• 4 years ago

-Sometimes for conversations about alternatives

So then submit a post mortem and drive the discussion there. Or alternatively post a "Ask HN" if you're legitimately considering alternatives.

-Sometimes for conversations about the product's stability history

Which are readily available on those provider's status pages.

-Sometimes just for solidarity in frustration

Isn't that what Twitter is for? Why should the frontpage be littered with <insert provider here>

My point is this - let's say GH goes down 8x over 2 weeks for 10 minutes each. Should there be 8 posts on the frontpage about GH going down each time? No, there should be ONE, otherwise the valuable discussions you're referring to get lost.

thieving_magpie2• 4 years ago

I can understand your viewpoint but just to offer a counter I always check HN for major outage news when it comes to github/AWS/GCP/Azure. There have often been comments with bits of information as to the cause and remediation efforts.

mbesto5• 4 years ago

bits of information as to the cause and remediation efforts.

That's what post mortems are for. Happy for people to submit those.

Also, why are cause and remediation efforts important to you? If you rely on the service and it goes out, what more are you going to learn here that would help you? Genuine question.

I always check HN for major outage news when it comes to github/AWS/GCP/Azure

Why not just check those status pages? Or check Twitter? HN seems like a weird place to check for it...

dtech• 4 years ago

The point is notifying the active community here and discussing the reason(s) and impact of the outage, or in GH's case their regularity I guess

mbesto5• 4 years ago

So then write a post that says "Ask HN: What is going on GH's being out X many of days". Otherwise you get 6 posts across weeks with the same discussion.

bob10292• 4 years ago

If there was no virtual public space in which to tar and feather shameful technical practices (or at least review them honestly), they would probably be even more prevalent.

I also see these as an excellent learning opportunity. Typically, it is a lesson in managing complexity.

FpUser• 4 years ago

I just got bunch of errors - error: failed to push some refs to 'github.com'. Luckily after a while the error disappeared.

I was going nuts. For my own products I use gitea and host repos myself. Some clients of mine however use github so in this case I have no choice

hirako2000• 4 years ago

'Be what's next', or how to ruin the brand of a 7.5B acquisition.

colinmhayes2• 4 years ago

Microsoft has big plans for github. Maybe the brand is a bit tarnished by the time they realize those plans, but if they succeed in fully integrating the developer productivity stack into both the github app and site they'll see a very large amount of revenue.

JonChesterfield2• 4 years ago

What GitHub app? edit: turns out to be a flavour of vendor lock in, https://docs.github.com/en/developers/apps/getting-started-w...

lolspace• 4 years ago

Thanks! Just had problem

arnonejoe• 4 years ago

can't open a PR right now.

thadjo• 4 years ago

pretty wild how these outages are basically just tolerated now. folks just get some coffee refresh HN a dozen times and then resume work when it comes back online. no huge uproar, no exodus from GH

dogleash2• 4 years ago

It was a foreseeable inevitability that once SaaS took over from on-prem that the quality would degrade to what we were getting from on-prem.

...but if you said anything you were just interrupting people playing with their new toys.

The shrug whatever coffee break while another department fixes things is the same now as it was back then.

corobo3• 4 years ago

Everyone with projects small enough to kneejerk move around migrated to GitLab when Microsoft bought GitHub

higeorge13• 4 years ago

Instead of releasing unnecessary social-like stuff they should have focused on their core git service. Seriously, what’s their uptime? Do they even have a number somewhere? Actions must be down every second day or so.

intunderflow• 4 years ago

With all the recent incidents have they broken their SLAs yet?

ProAm• 4 years ago

A SAAS company never breaks an SLA. SLA's are written by the legal team. Uptime is maintained by the engineering team. They aren't even in the same building.

AlexandrB• 4 years ago

Yup. After all this isn't downtime, its "degraded performance":

Git Operations is experiencing degraded performance. We are continuing to investigate.

bob10292• 4 years ago

Ah the semi-daily github fuckup.

For this one, I found myself rage-screaming at my monitor as their issue markdown preview API was timing out ~80% of the time.

Github enterprise is probably happening for us this year. I don't give a shit about the new features in the public build. I just want it stable and working at this point.

grumple• 4 years ago

Was wondering about multi-remote git workflow and found this: https://jigarius.com/blog/multiple-git-remote-repositories

This gets tougher with CI/CD though. How urgent is it to run your tests or deploy right now as opposed to when the outage is resolved later, or tomorrow? In emergencies I think you need ways to deploy without the CD pipeline (for those that can't currently).

In my experience there's always more work to do and downtime is a temporary inconvenience. Of course... my customers would be blowing up our phones and emails if we were down, threatening to quit, etc. I assume Github doesn't have quite the same level of pain when they have downtime.

teaearlgraycold• 4 years ago

Has anyone made a good SaaS product for self-hosted Github Actions runners? I'd gladly pay for beefier VMs from a 3rd party provider. Actually self-hosting is a pain in the ass because Github gives you only the runner software but none of the containerization/stateless wrapping I'd expect. Without some containers and scripting you'll get permanent changes to your VM's filesytem as you run actions.

And the VMs GitHub provides are far too low spec to run Cypress in. There's no option to pay for more resources.

yuuta• 4 years ago

Microsoft SRE always sucks. GitHub is just another victim.

tokumei• 4 years ago

It seems incidents like this with the big providers are becoming a lot more common. Wonder why that is

nrvn• 4 years ago

Github is a platform that comes with all platform-related risks, i.e. operational risk of having the whole development and SDLC lifecycle blocked, creating a vendor lock due to using some unique github features, inability to rely on third-party dependencies hosted on github.

There are a couple of strategies one could rely on to mitigate the risk of github downtime:

- create a map of features between github and competitors, find the common denominator and risk accept anything that is unique to github but viral for your business/product;

- maintain a primary self hosted instance of gitea/gitlab/sourcehut and use github as a mirror; - use github as a primary platform, maintain mirror with public gitlab and switch to gitlab in case of outage;

- if github is used beyond its primary purpose(git hosting) put some efforts to maintain the same features in gitlab/gitea/sourcehut, i.e. use CI features of both platoforms and push releases and artifacts to both of them so that end users have the choice.

- separate concerns and not go all in with github as a platform for the whole SDLC and project management and instead use different tools/platforms for different purposes.

Yes, it takes more time for the initial setup but it quickly pays back.

The above applies to those cases where your products need to be hosted publicly.

KronisLV• 4 years ago

Someone who decided to self-host their own source control system here, figured i'd comment about some of my experience due to some people mentioning it as an alternative. I've personally run GitLab in my own homelab for a few years but after some updates going wrong, i eventually moved over to Gitea, Nexus and Drone, also self-hosted: https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-...

GitLab is a large and complicated piece of software, which is a double edged sword: you do get an integrated issue tracking solution, Docker Registry with integrated access controls, as well as a pretty decent CI solution, which is great. At the same time, however, there's a chance for one of those subsystems to start misbehaving and bring down the whole thing (e.g. Omnibus install with default configuration for where to store container images --> running out of space; especially relevant if you don't find a good way to clean up old images), which may or may not be harder to solve than having 3 separate integrated systems.

Also, GitLab is pretty resource hungry and migrating to another solution actually improved the performance of certain systems/parts of functionality bunches: Gitea is really fast, Drone CI is about on par with GitLab CI and Nexus is a bit faster than GitLab Registry, however also eats too much RAM (e.g. the same problem within both Ruby and Java, Nexus seems to fail to start up below having approx. 1 GB of RAM, GitLab needed at least 2 - 3 GB of RAM).

However, running GitLab at work is still a pretty good idea, as long as keeping the instance up and running, as well as updated is someone else's responsibility and you can focus on just being the end user. At the same time, however, the update paths can be problematic sometimes, as was the case with my container based Omnibus installation that was multiple major versions out of date.

But for personal use? The Gitea, Nexus and Drone setup is perfectly sufficient, alongside maybe some issue tracking software (be it Kanboard, OpenProject or something else). In short, to the folks who are considering self-hosting in the comments: you can definitely try it out and have it be a learning experience, maybe on an affordable VPS or a device you have laying around!

Furthermore, there's nothing really preventing you from mirroring your repos over and keeping them in multiple systems, alongside any backups that you might be making!

AtNightWeCode• 4 years ago

What surprises me with many of the outages from big companies is that it seems like they have a bad setup when it comes to zone redundancy. Fact is many of the smaller companies I worked with are much better at this. Facebook, Fastly, Github. How can companies like that fail at such basic concepts? Really mind boggling. There must be something fundamentally flawed in their development process.

benmanns• 4 years ago

Perhaps they've all gotten big enough to run their own DNS?

GitHub Incident

Related Stories