Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub's Historic Uptime

damrnelson.github.io

Post reply on HN
Print view View original

61–70 of 131 posts

Re: GitHub's Historic Uptime

#61

Post by mememememememo »

fwip wrote: post #41
fontain wrote: post #22

Earlier 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”?

I think reasonable people can disagree on this. From the point of view of an individual developer, it may be "fraction of tasks affected by downtime" - which would lie between the average and the aggregate, as many tasks use multiple (but not all) features. But if you take the point of view of a customer, it might not matter as much 'which' part is broken. To use a bad analogy, if my car is in the shop 10% of the tim…

Or if your kettle is not working the house is considered not working?

Re: GitHub's Historic Uptime

#62

Post by hadlock »

nmaleki wrote: post #46
phillipcarter wrote: post #12

FWIW 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...

You'd think they'd do all the testing elsewhere and use a much shorter window of time to implement Azure after testing. I don't think this fully explains over 6 years of poor uptime.

The fact that even they struggle with github actions is a real testimate to the fact that nobody wants to host their own CD workers.

Re: GitHub's Historic Uptime

#63

Post by verdverm »

mort96 wrote: post #48
verdverm wrote: post #33

Earlier quoted context omitted.

It looks like the aggregate stats are more of a venn diagram than an average. So if 1/N services are down, the aggregate is considered down. I don't think this is an accurate way to calculate this. It should be weighted or in some way show partial outages. This belief is derived from the Google SRE book, in particular chapters 3 (embracing risk) and 4 (service level objectives) https://sre.google/sre-book/embracing-r…

I mean I think it's useful. It answers the question, "what percentage of the time can I rely on every part of GitHub to work correctly?". The answer seems to be roughly 90% of the time.

I don't use half of the services, the answer is not straight forward

https://mrshu.github.io/github-statuses/

Re: GitHub's Historic Uptime

#64

Post by barryhennessy »

It’s actually great to see a living example of how sensitive users* are to what to a lay person would look like a small amount of downtime.

The fact that we’re all talking about it, and not at all surprised, is a great example we can take when making the case for more 9’s of reliability.

* well, very technical power users.

Re: GitHub's Historic Uptime

#65

Post by verdverm »

otterley wrote: post #51

I'm not a GitHub apologist, but that graph isn't at scale, at all. It's massively zoomed in, with a lower band of 99.5%. It makes it look far worse than it is.

It's an uptime chart and shouldn't need to show much more than the 99% range.

If you started the y-axis at zero, you wouldn't see much of anything. Logarithmic scale would still be a bit much imo.

Re: GitHub's Historic Uptime

#67

Post by verdverm »

agilob wrote: post #15
BadBadJellyBean wrote: post #5

I feel like by now GitHub has a worse downtime record than my self hosted services on my single server where I frequently experiment, stop services or reboot.

It's ok because we're still paying for it. QoS degradation is worth it. No need to have 99.999% then you can have 90.84% and still people to pay for it.

Those electricity savings can better used to fuel the token bonfire

Re: GitHub's Historic Uptime

#68

Post by padjo »

shrinks99 wrote: post #14

I got Claude to make me the exact same graph a few weeks ago! I had hypothesized that we'd see a sharp drop off, instead what I found (as this project also shows) is a rather messy average trend of outages that has been going on for some time. The graph being all nice before the Microsoft acquisition is a fun narrative, until you realize that some products (like actions, announced on October 16th, 2018) didn't exist…

It feels like they launched actions and it quickly turned out to be an operations and availability nightmare. Since then, they've been firefighting and now the problems have spread to previously stable things like issues and PRs

Re: GitHub's Historic Uptime

#69

Post by marcosdumay »

BadBadJellyBean wrote: post #5

I feel like by now GitHub has a worse downtime record than my self hosted services on my single server where I frequently experiment, stop services or reboot.

It does have a worse downtime record than my tiny VPS that has a recurrent packet routing problem and keeps going offline. Measurably so.

Re: GitHub's Historic Uptime

#70

Post by mort96 »

mememememememo wrote: post #56
mort96 wrote: post #49

Earlier 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.

What is Google's uptime (including every single little thing with Google in the name)?

I don't think that's a fair comparison. Google Maps, Google Calendar, Google Drive, Google Search, Google Chrome, Google Ads, etc. are all clearly completely different products which have very little to do each other, they're just made by the same company called Google.

GitHub is a different situation. There's one "thing" users interact with, github.com, and it does a bunch of related things. Git operations, web hooks, the GitHub API (and thus their CLI tool), issues, pull requests, Actions; it's all part of the one product users think of as "GitHub", even if they happen to be implemented as different services which can fail separately.

EDIT: To illustrate the analogy: Google Code, Google Search and Google Drive are to Google what Microsoft GitHub, Microsoft Bing and Microsoft SharePoint are to Microsoft.

Post reply on HN