GitHub published an update on availability:

increase GitHub’s capacity by 10X

and then:

30X today’s scale

I had just been talking with the team about this exact thing: GitHub must be feeling the load from everyone coding with agents.

The obvious part is more code. The less obvious part is the shape of the work:

  • more branches
  • more commits
  • more pull requests
  • more Actions runs
  • more API calls
  • more retries
  • longer PR descriptions written by agents who have never met a concise paragraph they liked

GitHub says it started a 10X capacity plan in October 2025. By February 2026, it was already planning for 30X.

A 3X increase in the target within a few months is a wild adjustment.

GitHub included three scale markers:

  • pull requests merged: peaking near 90M/month
  • commits: peaking near 1.4B/month
  • new repositories: peaking near 20M/month

One quote from the post stuck with me:

The number of repositories on GitHub is growing faster than ever, but a much harder scaling challenge is the rise of large monorepos.

I had not thought enough about monorepos in the agent context. Agents work better when they can see the system. If context is scattered across a bunch of repositories, the agent has to go hunting. A monorepo makes the context problem simpler for the agent and harder for GitHub.

The pressure moves into PR pages, search, merge queues, code navigation, and CI.

GitHub’s own availability reports show a rough start to 2026:

  • January: 2 incidents
  • February: 6 incidents
  • March: 4 incidents
  • April: at least the merge queue and search incidents discussed in the availability update

I would still be careful about turning that into a grand theory. It is not enough data to say “GitHub got worse after Microsoft bought it.”

It is enough to say GitHub is under real pressure right now.

I also have a hard time dunking on GitHub too much. I use it constantly. My team uses it constantly. Some of our automated tools use it while I am asleep.

For Msty, GitHub Actions has been one of the painful spots. Some Linux builds that took 30+ minutes on GitHub-hosted runners are now down to a few minutes after moving them to Blacksmith. Mac builds are still slow. A local Mac build can take under 10 minutes while the CI version can take more than an hour.

So this line was good to see:

Next we focused on isolating critical services like git and GitHub Actions from other workloads and minimizing the blast radius by minimizing single points of failure.

GitHub Actions being treated as critical infrastructure feels right. For a lot of teams, CI is no longer a side channel. It is part of the coding loop.

I am also glad GitHub has Microsoft and Azure behind it for this phase. Going from 1X to 10X to 30X is not a normal infrastructure project. If there was ever a moment where a giant cloud parent helps, this is probably it.

The agent era is going to stress boring systems: Git, CI, search, queues, permissions, billing, and review pages.

Models get the attention. GitHub gets the traffic.