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

81–90 of 131 posts

Re: GitHub's Historic Uptime

#81

Post by verdverm »

marcosdumay wrote: post #57
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…

That's how you count uptime. You system is not up if it keeps failing when the user does some thing. The problem here is the specification of what the system is. It's a bit unfair to call GH a single service, but it's how Microsoft sells it.

> That's how you count uptime.

It's not how I and many others calculate uptime. There is not uniformity, especially when you look at contracts.

Re: GitHub's Historic Uptime

#82

Post by phillipcarter »

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.

It certainly explains the issues _now_, IMO.

Re: GitHub's Historic Uptime

#83

Post by BitsAndObjects »

tonymet wrote: post #73
BitsAndObjects wrote: post #71

Earlier quoted context omitted.

I was with you until your comment about vibe coders. Microsoft paid for and brought this vibe coding hell upon themselves. GitHub Copilot, investment in/partnership with OpenAI, and everything else they’ve done to enshitify software and the internet. If it brings them down, they’ve only themselves to blame. More likely it’ll just hasten the end of free public repos, which will be a shame, but we’ll find other ways to…

The smothering would happen with or without Copilot. This just sounds like an excuse to be ungrateful . I hope GitHub shuts down free tier , maybe developers will finally be grateful .

I’m grateful for GitHub and their support for open source, but they’re not getting any sympathy for the AI mess they’re generating (and they’re contributing more to the mess than many other organisations, due to their size, position and product strategy).

They’re a big enough corporation that we can have nuanced feelings about them. Simultaneously grateful for one part of what they do, and unsympathetic for the consequences of a different part of what they do.

Re: GitHub's Historic Uptime

#84

Post by verdverm »

ablob wrote: post #54
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…

If you're using all services, then any partial outage is essentially a full outage. Of course, you can massage the numbers to make it look nicer in the way you described but the conservative approach is better for the customers. If you insist, one could create this metric for selected services only to "better reflect users". That being said, even when looking at the split uptimes, you'd have to do a very skewed weigh…

> That being said, even when looking at the split uptimes, you'd have to do a very skewed weighting to achieve a number with more than one 9.

It's definitely bad no matter how it you slice the pie.

If GH pages is not serving content, my work is not blocked. (I don't use GH pages for anything personally)

Re: GitHub's Historic Uptime

#85

Post by pikzel »

OlivOnTech wrote: post #42
fishtoaster wrote: post #20

Is the pre-2018 data actually accurate? There seem to have been a number of outages before then: https://hn.algolia.com/?dateEnd=1545696000&dateRange=custom&... Maybe that's just the date when they started tracking uptime using this sytem?

Data comes from the official status page. It may be more a marketing/communication page than an observability page (especially before selling)

The status page was often down when GH was down, back in the days.

Re: GitHub's Historic Uptime

#86

Post by tonymet »

BitsAndObjects wrote: post #83
tonymet wrote: post #73

Earlier quoted context omitted.

The smothering would happen with or without Copilot. This just sounds like an excuse to be ungrateful . I hope GitHub shuts down free tier , maybe developers will finally be grateful .

I’m grateful for GitHub and their support for open source, but they’re not getting any sympathy for the AI mess they’re generating (and they’re contributing more to the mess than many other organisations, due to their size, position and product strategy). They’re a big enough corporation that we can have nuanced feelings about them. Simultaneously grateful for one part of what they do, and unsympathetic for the conse…

true colors.

Re: GitHub's Historic Uptime

#88

Post by esseph »

hadlock wrote: post #62
nmaleki wrote: post #46

Earlier quoted context omitted.

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.

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

What a weird takeaway

Re: GitHub's Historic Uptime

#89

Post by jrochkind1 »

Honestly I think their status page just got more honest -- and they are graphing this in such a way that any partial outage to any service looks really bad on teh chart.

There were definitely partial outages to services inside that row of horizontal green dots, that the status page just wasn't advertising.

Re: GitHub's Historic Uptime

#90

Post by irishcoffee »

lcnPylGDnU4H9OF wrote: post #32
irishcoffee wrote: post #17

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

The same philosophy would suggest that running some other command immediately following a particular (successful) git command is fine; it is composing relatively simple programs into a greater system. Other than the common security pitfalls of the former, said philosophy has no issue with using (for example) Jenkins instead of Actions.

[flagged]
Post reply on HN