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.
Incident with Issues and Webhooks – Resolved
151–160 of 275 posts
Re: Incident with Issues and Webhooks – Resolved
#152Github 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, for one, am not paying them enough money to expect any better.
Re: Incident with Issues and Webhooks – Resolved
#153Earlier quoted context omitted.
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…
I wonder how many of those actions are really necessary
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.
Re: Incident with Issues and Webhooks – Resolved
#154Earlier 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…
What are you referring to when you say it's "fundamentally computationally inefficient"? It's pretty efficient because it's content-addressed, plus optimizations to reduce storage and data transfer with packfiles.
Re: Incident with Issues and Webhooks – Resolved
#155Re: Incident with Issues and Webhooks – Resolved
#156Earlier quoted context omitted.
This is extremely interesting how fast this happened. Either AI use surged massively in the last quarter, or this is a very sneaky move by Anthropic. Looking at my own stats, I don't think I'm using Claude Code much more than I used to, but my commits have gone way up. I have a feeling they've tuned the models recently to commit more often, which gives the illusion of more work being done.
I don't think commits per se puts pressure on the infrastructure. More likely pulls and pushes, and, naturally, the ci minutes they identify as the main issue.
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.
Re: Incident with Issues and Webhooks – Resolved
#157Honestly, if GH keeps getting worse I may need to migrate away to Forgejo or something. The problem is GHA... Does anyone know of a service that is better and doesn't charge me an arm and a leg for runners (particularly MacOS ones)? I've been wanting to shift away from GHA for ages (because I hate it) but I don't know of any alternatives that are quite like it (or the costs involved).
Re: Incident with Issues and Webhooks – Resolved
#158Would it reduce their load if every AI instance both local and centralized had their own local git repo (and/or Gerrit instance) and then only committed for a sub-set of specific conditions were met?
Re: Incident with Issues and Webhooks – Resolved
#159Github 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…
I've been a strong proponent of reallocating all LinkedIn server capacity to GitHub.
[flagged]
Re: Incident with Issues and Webhooks – Resolved
#160Github 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…
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’…
I noticed the same https://news.ycombinator.com/item?id=47940213. My working hypothesis is that, given that a filter was always required (prs and issues are likely rows in the same database with a bool property to distinguish them), someone thought it'd be good to use the search API uniformly. But search is on the derivative of the underlying data, in contrast to the specific APIs for listing issues and prs.