GitHub’s CTO says the company must overhaul parts of its architecture after an August 17 outage disrupted core developer workflows for 7 hours and 47 minutes, according to The Register. The incident affected services including Actions, pull requests, issues, Copilot, and application programming interfaces, the report says. “If you were trying to ship software that day, we let you down,” CTO Vladimir Fedorov wrote, according to The Register. The outlet notes that Fedorov offered more detail on the outage while avoiding the word “sorry.” The company’s message, as reported, was less about a single bad release than about scaling pressure across a platform that developers depend on for day-to-day software delivery. The August 17 failure followed another outage involving GitHub Actions on August 6, The Register reports. GitHub had also acknowledged in April that the platform had been “wobbly,” according to the outlet, and that reliability work had not kept pace with rising usage. The scale figures in the report show why the problem is difficult to contain. The Register says GitHub reported 1.4 billion monthly commits in April. It now says it handles 2.9 billion commits, 24 million new repositories, and 130 million merged pull requests each month. GitHub’s infrastructure is already heavily tied to Microsoft Azure. According to The Register, Azure handles about 58% of GitHub’s platform load and half of all Git operations. Fedorov said GitHub has accelerated moving more workloads to its parent company’s cloud, the report says. The longer-term plan centers on read capacity. Fedorov described the next milestone as an architecture that scales read capacity linearly with the number of readers, enabling “unlimited read operations,” according to The Register. GitHub plans to roll that out gradually, beginning with the largest monorepos. Before that architecture arrives, GitHub is working on narrower reliability fixes. The Register reports that the company plans to isolate critical systems to reduce the blast radius of future failures, tighten retry limits, and add alerts for early signs of traffic spikes. Fedorov also said neither August outage was caused by a code or configuration change, meaning the failure modes were already present rather than introduced by a new deployment. For engineering organizations, the important point is not only that GitHub went down, but that GitHub is framing the incident as a scaling and resilience problem. Retry storms, traffic spikes, misconfigured limits, and shared critical paths can turn localized stress into broad platform failure. GitHub’s response, as described by The Register, is to reduce coupling, constrain retries, and add capacity where read demand is growing fastest. The Register reports that developer reaction has been mixed: some users expressed sympathy for the complexity of operating GitHub at its scale, while paying customers voiced frustration that the service is falling short. Fedorov closed by saying the developer community depends on GitHub to build, ship, and operate its work, and that GitHub’s responsibility is to earn back trust through scaling and reliability improvements. Who benefits: Developers and companies using GitHub’s largest repositories would benefit first if the planned read-scaling architecture performs as described. Microsoft Azure also stands to remain central as GitHub moves more workload onto its parent company’s cloud. Who's exposed: Teams that rely heavily on GitHub-hosted workflows are exposed to platform-level outages that can interrupt shipping. The report does not provide enough detail to quantify customer impact beyond the services affected and the outage duration.