GitHub adds four million CPU cores to prevent outages

What happened

GitHub is adding around four million extra CPU cores to its infrastructure and re-architecting parts of its site so the platform can absorb rising load without going offline, according to reporting by The Register. The change is framed as a response to a surge in traffic that the outlet links to AI-generated activity, which it describes informally as "AI slop."

The Register's coverage positions the capacity expansion as a reliability measure rather than a feature launch. The goal is to keep the service available as demand grows, and the re-architecture suggests the scaling problem is structural rather than solvable by adding hardware alone.

The report is a single-source account, so details of the timeline, cost and specific architectural changes should be checked against GitHub's own communications before being relied on.

Why it matters

For a platform that many engineering teams depend on daily, an outage is an experience failure as much as a technical one. Developers who cannot push code, review changes or run pipelines feel the disruption directly, and the trust cost of repeated downtime tends to outlast the incident itself. Investing ahead of demand is therefore a service decision, not only an infrastructure one.

The wider signal is that automated and AI-generated activity is now shaping capacity planning for digital services. Organisations that have treated traffic as a predictable function of human users may need to model machine-driven demand, including bursts and low-value requests, as a distinct load profile. That affects how they design rate limits, caching, observability and the way they communicate degraded performance to users.

By the numbers

• 4 million additional CPU cores reported as part of GitHub's capacity expansion
• 28 October 2026 publication date of The Register's report

The Renascence take

Most commentary will treat this as a scaling story about buying more compute. The more useful reading is that reliability at this level is now a design problem: if the traffic mix has changed, the architecture has to change with it.

Adding capacity buys time, but it does not fix a system that was built for a different kind of user. The behavioural principle underneath is that every request a platform serves shapes the experience of the people who actually need it, so triaging low-value demand is as much a service decision as a technical one. Customer-obsessed operators should map which traffic serves real users and which does not, then build graceful degradation, clear status communication and priority lanes before the next surge rather than after it.