34 comments

[ 2.7 ms ] story [ 73.9 ms ] thread
My favourite part of this is the "All systems operational" in green at the top. Yet, all systems are clearly not operational.
That's the system that's not operational.
Didn't Github comment on their blog recently [1] on how they were improving and reducing failure detection times? Doesn't speak well for them if it's first on Hacker News and not their own Status page.

tl;dr; > One of the biggest customer-facing effects of this delay was that status.github.com wasn't set to status red until 00:32am UTC, eight minutes after the site became inaccessible. We consider this to be an unacceptably long delay, and will ensure faster communication to our users in the future.

EDIT: "We're investigating some issues with our databases".

[1] https://github.com/blog/2106-january-28th-incident-report

>09:56 CEST "We're investigating some issues with our databases".

Update:

>10:03 CEST "Everything operating normally."

The graphs show the downtime even while the green was at the top. My guess would be that its just something that someone as to toggle.
I have the feeling that this is happening more and more these days. And it's a mayor problem when a large part of your infrastructure is depending on services like Github (composer, etc.)
Let's see how long it takes for people to realize how good an idea it is to rely on this single point of failure for potentially critical systems..
It's an issue for people at large to have this shared point of failure, but not for any particular individual.
It's kind of ironic when one realizes that one of the major design goals of git was to be distributed, to reduce dependency on a single point of failure.
GitHub isn't really a single point of failure. You could easily keep working on your branches and/or forks and re-sync once the server is back up.
That's definitely true, but PRs, comments and bug reports are not distributed, nor are many bridges between Github and external tools (issue trackers like JIRA/Trello, build-servers). This might seem pedantic, but it creates an asymmetry: commits and branches distributed, as opposed to PRs and comments.
A shame... And the github status webpage says everything is fine.
Well, this is a good excuse to not do any work
Ir works for me
Up for me too, all systems seem to be operational. Located in Europe if that matters, not sure how GitHub is geographically distributed.
(comment deleted)
Do we really need a new thread every time GH is down for 5 minutes?

Also, please use GitLab.

The last time GitHub went down was in January and it was over two hours.

What prevents GitLab from going down like GitHub?

Update: Yeah, maybe if we run an own GitLab instance in our corporate network.

Update update: Hmm, there seem to be outages in February, March and April, too. Source: https://news.ycombinator.com/item?id=11736331

Any Git hosting provider as large as GH is also likely to go down once in a while. The bigger your scale is the more difficult it is to get nines.
I dunno, I'd see it as the opposite. The bigger the scale the more cost effective it is to have more redundancy. I can't remember the last time Google search wasn't working or saw news about it being down.

The fact that github keeps going down while being a huge business shows they still need to work on having more redundancy, something that's expected of big services like theirs.

well, a lot of people's work is reliant on it, so i'd say it's a pretty important thing.

> Also, please use GitLab.

and you can't just say "use xyz".

GitLab is and GitHub is NOT:

- Free

- Open source

- CI integrated

- Rapid development (because open-source)

01:56 Mountain Daylight Time "We're investigating some issues with our databases"