Incident with Issues and Webhooks – Resolved • Hacker News Board

Re: Incident with Issues and Webhooks – Resolved

#201

Post by siva7 » Mon, May 04, 2026, 5:51 PM UTC

eddyg wrote: post #77

AlexB138 wrote: post #15

Github has published some incredible usage rate increase numbers, which they ascribe to the rise of agentic coding. At some point, they are going to have to change rate limits, cut free-tier usage, or find some other path to reducing load. It's clear that their infrastructure can't keep up with this significant increase, and it's unlikely that they're going to just absorb the increased costs themselves. Very curious…

From the GitHub COO on April 3rd: Platform activity is surging. There were 1 billion commits in 2025. Now, it's 275 million per week, on pace for 14 billion this year if growth remains linear (spoiler: it won't.) GitHub Actions has grown from 500M minutes/week in 2023 to 1B minutes/week in 2025, and now 2.1B minutes so far this week. So we're pushing incredibly hard on more CPUs, scaling services, and strengthening G…

It's the end of the free lunch era. Subsidizing groups like students or new users to gain market share worked as long as there weren't billions of them at the same time eating all compute from the paying customers. It's not working anymore for ai products.

Re: Incident with Issues and Webhooks – Resolved

#202

Post by xp84 » Mon, May 04, 2026, 5:51 PM UTC

sofixa wrote: post #91

graemep wrote: post #66

Earlier quoted context omitted.

Your claim is incorrect. Something purely AI generated may not be covered by copyright in the US. That would make it more valuable to MS as you can reuse it as you like. However, works with significant human input are covered by copyright, and most code does have such input. Human review, and correction is very common. There is a lot of AI generated code out there, and there are no cases challenging the copyright on…

> However, works with significant human input are covered by copyright, and most code does have such input. Human review, and correction is very common. There is a lot of AI generated code out there, and there are no cases challenging the copyright on it. Legislation and court decisions still pending. There are numerous lawsuits about copyrigtability of output, and right of use of copyrighted work by LLMs, and both c…

If I write a program of 1000 lines of code, with AI features turned off, then I turned the AI features on and use a completion to edit one function, can my program not be copyrighted? (I expect/hope you’ll say: “Of course it’s still eligible for copyright”)

How about if I write 100 lines myself, turn the AI features on, vibe code 100 lines, and repeat this for five cycles? Half the functions are AI coded and half the functions I wrote myself. How about if I just tell Claude to write the program?

And what if I tell Claude to write the program, and then spend six months tweaking most of the lines of code?

I struggle to see a specific and obvious point where a line should be drawn. It seems intuitive to me that if I spend at least a few days worth of effort on a code base (whether tweaking, correcting, or directing AI to do targeted refactors), that is meaningful human authorship even if it has thousands of lines of generated code.

I can, however, acknowledge the fairness that something which is simply one-shot output probably shouldn’t merit protection. But really, in any of these cases, it’s going to be pretty hard to prove after the fact exactly what the proportion of generated code to human authorship is, so idk how a court will really tell whether a repo with 20,000 LOC is one-shot or actually had a person spend a few weeks tweaking it.

Re: Incident with Issues and Webhooks – Resolved

#203

Post by munk-a » Mon, May 04, 2026, 5:52 PM UTC

wavemode wrote: post #104

amluto wrote: post #52

Earlier quoted context omitted.

For literally decades, I’ve observed that there are systems that make each operation cheap and systems that work hard to scale out. The former frequently seems to wildly outperform the latter. GitHub, for example, seems to implement the main repository /pulls page as a search query, which is hinted at by the prefilled search bar and was mostly confirmed last week when the search backend failed and pull requests didn’…

Git itself is kind of a fundamentally computationally inefficient way to store and retrieve information. If the problem to solve were simply "store and version this text", 14 billion commits in a year would not even be considered a lot. In other words, a centralized version control system built from the ground up to operate at scale would do far more for scalability than anything GitHub could possibly do to optimize…

I can guarantee you one thing - github's problem isn't coming from git.

Considering all the ci/cd pipelines, PR & issue discussions, social media tracking, rich data and else that github hosts if their true issue is the actual meat and potatoes of running git I would be gobsmacked.

Re: Incident with Issues and Webhooks – Resolved

#204

Post by spockz » Mon, May 04, 2026, 5:52 PM UTC

munk-a wrote: post #177

NewJazz wrote: post #156

Earlier quoted context omitted.

But CI only increased by a factor of 2 since last year. Did they really not foresee that happening? And how does that affect git and api operations.

It really shouldn't. The technical summary they released[1] is a very interesting read from a software engineering perspective. It seems to be blindsided by the increased traffic and gives stats related to commits/PRs (which should be relatively cheap for github to process) without any insight into their web traffic or details on how much actions are costing them. If they were super transparent they'd release informa…

Re 2, I would generally agree and there is a lot that can be done with caching. However, since writing services in Rust and Golang, there is whole other tier in speed. Architecture matters, code quality also matters, but Golang and Rust help a lot in making very fast services.

Re: Incident with Issues and Webhooks – Resolved

#205

Post by pathartl » Mon, May 04, 2026, 5:54 PM UTC

brian-armstrong wrote: post #183

mohsen1 wrote: post #82

Earlier quoted context omitted.

The same company operates the Xbox network. More daily active users and more events per second

Not comparable at all. Xbox would be mostly transient traffic. It's probably not much more than packet forwarding for a lot of traffic. Github is a giant complicated stateful mess with a lot of reads and writes. It also has a lot of features at this point. Hard to scale and hard to optimize.

I think this is minimizing the Xbox platform. They are also a massive digital distribution platform where almost every game is a digital download now.

That being said, you are correct. It is absolutely no surprise to me that Actions has the worst uptime.

Re: Incident with Issues and Webhooks – Resolved

#206

Post by munk-a » Mon, May 04, 2026, 5:54 PM UTC

spockz wrote: post #197

PhilipRoman wrote: post #153

Earlier quoted context omitted.

And how many of those actions do uncached downloads instead of building self-contained offline images... Speaking of which, I wonder if GitHub has implemented any HTTP interception for common mirror sites, like used by apt, etc.

Many downloads now go over https. Intercepting them would require having certificate for those domains. IIRC on the clouds the standard images do have a sources list that points to mirrors on the cloud’s network. I would only presume Github Actions runners have the same. Not sure if something similar exists for NPM which is big for all things JS.

Other CI/CD platforms usually push you towards using self-hosted mirrors for downloading large chunks of data (often aggressively so) but github is pretty hands off when it comes to actions. It is interesting to consider whether managing that traffic might be overwhelming them and if this can be traced back to a lack of forethought when it came to building out those tools.

Re: Incident with Issues and Webhooks – Resolved

#207

Post by maccard » Mon, May 04, 2026, 5:55 PM UTC

afro88 wrote: post #148

pluc wrote: post #83

Earlier quoted context omitted.

It isn't. Lots of unacceptable things going on these days and everyone seems to be accepting them just fine.

Guarantee enterprises with SLAs aren't accepting them

The thing about an SLA is that once you’ve broken it you’ve lost the trust. It doesn’t _really_ matter what the cost is for breaking it, nobody chooses their platform based on the refund they’ll get if they’re down. But they absolutely do choose based on reliability and uptime. The enterprise SLA refund credit will show as a (big) metering blip, but the problem is the people who signed the contracts are going to be speaking to Gitlab now

Re: Incident with Issues and Webhooks – Resolved

#208

Post by booleandilemma » Mon, May 04, 2026, 5:55 PM UTC

pluc wrote: post #83

gejose wrote: post #30

Github has 84.92% uptime in the last 90 days according to https://mrshu.github.io/github-statuses I don't know how this is even remotely close to acceptable.

It isn't. Lots of unacceptable things going on these days and everyone seems to be accepting them just fine.

I think the default position people like to take generally is to just go with the status quo. GitHub has reached status quo level. As in "nobody ever got fired for choosing GitHub". It's the only forge I've seen advertisements for in the meatspace, and even non-technical people know about it. On job applications, companies ask for my GitHub URL. I think it'll be awhile now before they get abandoned. That said, I recently started moving my stuff over to Codeberg. The change needs to start with us, the people writing software.

Re: Incident with Issues and Webhooks – Resolved

#209

Post by cphoover » Mon, May 04, 2026, 5:56 PM UTC

jfrbfbreudh wrote: post #151

Reduce the free tier. I’ve made 4000 commits in the last 2.5 months. That’s just to main. And I push up tons of artifacts daily for regression testing. For $0.

They do that and open source projects that haven't left already will migrate.

Re: Incident with Issues and Webhooks – Resolved

#210

Post by munk-a » Mon, May 04, 2026, 5:56 PM UTC

spockz wrote: post #204

munk-a wrote: post #177

Earlier quoted context omitted.

It really shouldn't. The technical summary they released[1] is a very interesting read from a software engineering perspective. It seems to be blindsided by the increased traffic and gives stats related to commits/PRs (which should be relatively cheap for github to process) without any insight into their web traffic or details on how much actions are costing them. If they were super transparent they'd release informa…

Re 2, I would generally agree and there is a lot that can be done with caching. However, since writing services in Rust and Golang, there is whole other tier in speed. Architecture matters, code quality also matters, but Golang and Rust help a lot in making very fast services.

Yeah I don't disagree. To clarify. Rust, Golang etc - they give you a very noticeable advantage when it comes to writing good performant software with the assumption that you're putting in the effort on the design side. But poorly written Rust is likely going to be indistinguishable from poorly written Ruby.