5 ms·

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 bi

by eddyg 5mo ago

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 GitHub’s core features. https://x.com/kdaigle/status/2040164759836778878 https://x.com/kdaigle/status/2040164759836778878 They also had a recent blog post about availability: https://github.blog/news-insights/company-news/an-update-on-github-availability/ https://github.blog/news-insights/company-news/an-update-on-... I don't envy the scaling issues the GitHub engineers are facing! #HugOps

wolfi1 5mo ago
I wonder how many of those actions are really necessary
- bravetraveler 5mo ago
  Or how many pushes those commits are spread across; oh, neat, big number.
- PhilipRoman 5mo ago
  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.
  - spockz 5mo ago
    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.
    - munk-a 5mo ago
      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.
  - everfrustrated 5mo ago
    GitHub and WarpBuild cache is so slow it is often faster to re-download hundreds of MB each run than cache it properly. I so wish this wasn't the case.
hansmayer 5mo ago
Wow, nice to see the relentless push for more AI slop finally paying back some dividents back to the issuer.
skylerwiernik 5mo ago
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.
- tossandthrow 5mo ago
  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.
  - NewJazz 5mo ago
    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.
    - munk-a 5mo ago
      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 information about their request response time and resourcing to fulfill that. Their current path to resolution is to migrate their codebase to a new language[2], continue to drop their inhouse ops for Azure resources and get off MySQL. Maybe one or two of those steps are legitimately a good idea - I don't have an inside scope - but technology migrations are always fraught with issues. It's quite possible these changes are just a result of them vibe-coding a mature codebase into a new language. 1. https://github.blog/news-insights/company-news/an-update-on-github-availability/ https://github.blog/news-insights/company-news/an-update-on-... 2. I'll grant that Ruby isn't the best language to use as scale but I think we're all old enough to realize that language choice is far less impactful on performance than code quality.
munk-a 5mo ago
After the Microsoft acquisition GH marketing and pricing put an immense amount of effort[1] into trying to kill secondary platforms that integrated into github and move more corporate accounts fully on-platform. We recently dropped travis for github actions and dropped reviewable for github PRs (which are terrible). There's a portion of this that is agentic driven and there's a portion of this that's just github making their own bed. 1. Arguably anticompetitive pricing like MSFT is used to doing with the office suite.
- foolswisdom 5mo ago
  In other words, the set of github core services has expanded because you don't use third party tooling for some of those services anymore.
  - munk-a 5mo ago
    For us, yes - and likely for a lot of other users. I'm not certain who else has dealt with the headache of being migrated off their legacy pricing plan but it ends up pushing those internal offerings a lot harder than the old approach did so if they're seeing successful conversions it's likely they're seeing significantly more load from mature codebases with expensive CI/CD pipelines.
- blks 5mo ago
  That sounds like their classic EEE
siva7 5mo ago
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.
- po1nt 5mo ago
  Not a free lunch, data gold mine
sgt 5mo ago
They can easily spin this as massive success. Uptime will only matter for a small number of users. Probably not true, but not far from the truth either. I'm a heavy Github user and I can't really say it's THAT bad. If something doesn't work, you can always fill your time with something else.

by eddyg 5mo ago

wolfi1 5mo ago

I wonder how many of those actions are really necessary

bravetraveler 5mo ago
Or how many pushes those commits are spread across; oh, neat, big number.
PhilipRoman 5mo ago
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.
- spockz 5mo ago
  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.
  - munk-a 5mo ago
    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.
- everfrustrated 5mo ago
  GitHub and WarpBuild cache is so slow it is often faster to re-download hundreds of MB each run than cache it properly. I so wish this wasn't the case.

hansmayer 5mo ago

Wow, nice to see the relentless push for more AI slop finally paying back some dividents back to the issuer.

skylerwiernik 5mo ago

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.

tossandthrow 5mo ago
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.
- NewJazz 5mo ago
  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.
  - munk-a 5mo ago
    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 information about their request response time and resourcing to fulfill that. Their current path to resolution is to migrate their codebase to a new language[2], continue to drop their inhouse ops for Azure resources and get off MySQL. Maybe one or two of those steps are legitimately a good idea - I don't have an inside scope - but technology migrations are always fraught with issues. It's quite possible these changes are just a result of them vibe-coding a mature codebase into a new language. 1. https://github.blog/news-insights/company-news/an-update-on-github-availability/ https://github.blog/news-insights/company-news/an-update-on-... 2. I'll grant that Ruby isn't the best language to use as scale but I think we're all old enough to realize that language choice is far less impactful on performance than code quality.

munk-a 5mo ago

After the Microsoft acquisition GH marketing and pricing put an immense amount of effort[1] into trying to kill secondary platforms that integrated into github and move more corporate accounts fully on-platform. We recently dropped travis for github actions and dropped reviewable for github PRs (which are terrible). There's a portion of this that is agentic driven and there's a portion of this that's just github making their own bed. 1. Arguably anticompetitive pricing like MSFT is used to doing with the office suite.

foolswisdom 5mo ago
In other words, the set of github core services has expanded because you don't use third party tooling for some of those services anymore.
- munk-a 5mo ago
  For us, yes - and likely for a lot of other users. I'm not certain who else has dealt with the headache of being migrated off their legacy pricing plan but it ends up pushing those internal offerings a lot harder than the old approach did so if they're seeing successful conversions it's likely they're seeing significantly more load from mature codebases with expensive CI/CD pipelines.
blks 5mo ago
That sounds like their classic EEE

siva7 5mo ago

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.

po1nt 5mo ago
Not a free lunch, data gold mine

sgt 5mo ago

They can easily spin this as massive success. Uptime will only matter for a small number of users. Probably not true, but not far from the truth either. I'm a heavy Github user and I can't really say it's THAT bad. If something doesn't work, you can always fill your time with something else.