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

71–80 of 131 posts

Re: GitHub's Historic Uptime

#71

Post by BitsAndObjects »

tonymet wrote: post #43

Nearly all the variance is from Actions, a product that didn’t exist beforehand. It’s despicable to see everyone punching down on GitHub. Even under Microsoft they’ve continued to provide an invaluable and free service to open source developers . And now , while vibe coders smother them to death, we ridicule them . Shameful , really

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 share code that aren’t reliant on one semi-benevolent megacorp.

Re: GitHub's Historic Uptime

#72

Post by formerly_proven »

verdverm wrote: post #33
montroser wrote: post #21

Earlier quoted context omitted.

It has been pretty rough. Their own numbers report just a single `9` for Actions in Feb 2026 with 98% uptime. But that said -- I don't get the 90% number. Anecdotally, it seems believable that 1 in 50 times (2%) in Feb that Actions barfed. Which is not very nice, but it wasn't at 1 in 10 times (10%).

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…

In a nutshell, why would the consumer care (for the SLO) care about how the vendor sliced the solution into microservices?

Re: GitHub's Historic Uptime

#73

Post by tonymet »

BitsAndObjects wrote: post #71
tonymet wrote: post #43

Nearly all the variance is from Actions, a product that didn’t exist beforehand. It’s despicable to see everyone punching down on GitHub. Even under Microsoft they’ve continued to provide an invaluable and free service to open source developers . And now , while vibe coders smother them to death, we ridicule them . Shameful , really

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 .

Re: GitHub's Historic Uptime

#75

Post by wang_li »

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…

A better analogy is if one bulb in the right rear brake light group is burnt out. Technically the car is broken. But realistically you will be able to do all the things you want to do unless the thing you want to do is measure that all the bulbs in your brake lights are working.

Re: GitHub's Historic Uptime

#76

Post by fwip »

remus wrote: post #52
fwip wrote: post #41

Earlier quoted context omitted.

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…

> 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 time, it's not much comfort if each individual component is only broken 0.1% of the time. Not to go too out of my way to defend GH's uptime because it's obviously pretty patchy, but I think this is a bad analogy. Most customers won't have a hard reliability o…

Sorry, by 'customer' I meant to say something like a large corporate customer - you're buying the whole package, and across your org, you're likely to be a little affected by even minor outages of niche services.

But yeah, totally agree that at the individual level, the observed reliability is between 90% and 99%, and probably toward the upper end of that range.

Re: GitHub's Historic Uptime

#77

Post by verdverm »

formerly_proven wrote: post #72
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…

In a nutshell, why would the consumer care (for the SLO) care about how the vendor sliced the solution into microservices?

It will depend on the contract.

When I was at IBM, they didn't meet their SLOs for Watson and customers got a refund for that portion of their spend

Re: GitHub's Historic Uptime

#78

Post by otterley »

verdverm wrote: post #65
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.

> If you started the y-axis at zero, you wouldn't see much of anything.

That's... kind of my point.

As a reliability engineer, I'm disappointed in GitHub's 99.5% availability periods, especially as they impact paying customers. On the other hand, most users are non-paying users, and a 99.5% availability for a free service seems to me to be a reasonable tradeoff relative to the potential cost of improving reliability for them.

Re: GitHub's Historic Uptime

#79

Post by Kaliboy »

mort96 wrote: post #70
mememememememo wrote: post #56

Earlier quoted context omitted.

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 hook…

Completely agree, it makes it worse actually as Github's secondary functions so to speak are things we implicitely rely on.

When I merge to master I expect a deploy to follow. This goes through git, webhooks and actions. Especially the latter two can fail silently if you haven't invested time in observation tools.

If maps is down I notice it and immediately can pivot. No such option with Github.

Re: GitHub's Historic Uptime

#80

Post by pavon »

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.

If you plotted it from zero, then a horrible service and a great service would be indistinguishable. Their SLA for enterprise customers is 99.9%. The low end of that chart is 5x that amount downtime. It is a reasonable scale for the range people are concerned about and it looks bad because it is bad.
Post reply on HN