The reason for GitHub's approximately 8-hour downtime has been identified: the surge in usage caused critical infrastructure to fail to automatically scale, leading to a chain reaction of failures.
A global outage occurred at GitHub from August 17th to 18th, 2026, making many services, including GitHub.com, GitHub Actions, and GitHub Copilot, difficult to use. On August 20th, GitHub published its investigation results, explaining that critical infrastructure in its data centers in central the United States was unable to scale up its processing capacity in response to record-high traffic, leading to a chain reaction of outages.
The August 17 outage, and the work ahead - The GitHub Blog
The outage lasted for 7 hours and 47 minutes, from approximately 10:28 PM on August 17th to 6:15 AM on August 18th Japan time. At its peak, approximately 20% of web functions and APIs experienced errors, and approximately 50% of raw content downloads from archives and repositories experienced errors. The impact extended to Issues, Pull Requests, Actions, Copilot, and authentication functions.
GitHub is down worldwide - GIGAZINE
According to GitHub's investigation, the outage was triggered by record-high traffic. In a data center in central America, an auxiliary component called a 'sidecar' of 'Istio,' which mediates communication between services, reached its concurrent processing limit. However, the mechanism that automatically increases processing capacity only monitors the status of the main service and did not take into account the processing limit of the sidecar, so the necessary expansion was not carried out.
The capacity shortage then spread to other equipment. Ultimately, the four 'HAProxy' servers that distribute traffic reached their communication processing limits, causing delays and errors in GitHub's internal authentication pathway. Because the authentication function is used by numerous GitHub services, this resulted in a chain reaction of failures affecting a wide range of services, including GitHub.com and Actions.
What made recovery even more difficult was the 'retry' function, which automatically attempts to reconnect if communication fails. The large number of retries during the outage increased the load on the internal load balancer, and Visual Studio Code (VS Code) had a potential bug that caused a large number of retries if GitHub Copilot authentication failed. Access to the service that processes Copilot authentication tokens swelled from the usual 7,000 to 9,000 requests per second to 70,000 to 100,000 requests per second, which caused Copilot's recovery to be slower than other services.
GitHub explained that the August 17 outage was not directly caused by changes in code or configuration, but 'fundamentally due to insufficient storage capacity.' GitHub's usage has surged, with monthly commits doubling from 1.4 billion in April 2026 to 2.9 billion in approximately four months.
The graph below shows the trend in GitHub usage. Since 2023, the number of merged pull requests, new repositories, and commits per month has all increased sharply, reaching approximately 130 million merged pull requests, 2.9 billion commits, and 24 million new repositories in August 2026.
To cope with the rapidly increasing usage, GitHub has been strengthening its infrastructure for some time. To date, it has added more than 3 million CPU cores and 120 PB of high-speed storage, and has also significantly increased network capacity. In existing data centers, it is adding hardware within the limits of available power, and is also accelerating its migration to Microsoft Azure.
As of May 2026, Azure accounted for 12% of GitHub's total processing volume, but that figure has already increased to approximately 58%. Azure also handles about half of Git operations. This infrastructure expansion has also supported the increase in the number of GitHub Actions jobs executed; the number of Actions executed, which was in the tens of millions at the beginning of 2026, increased to 115.4 million in August.
GitHub is also working to improve performance when handling large repositories. With large repositories, many developers and systems read data simultaneously, so a mechanism is needed that can efficiently increase read processing as the number of users increases. GitHub is using Azure infrastructure and added processing power to support large-scale repositories, and has also released a graph showing the processing power when 'git fetch' is executed with a high degree of parallelism.
GitHub has stated that its next step will be to 'introduce an architecture that allows processing power to increase linearly with the number of reads, and will roll it out gradually, starting with the largest repositories,' and has released the graph shown below. In the graph, the processing volume remains at around 1000 times per second in the example on the left, while in the example on the right, the processing volume gradually increases to about 1800 times per second.
In addition to increasing processing capacity, GitHub will implement a mechanism to prevent 'retry storms,' where a large number of retries further increase the load, by setting a limit on the number of retries allowed in communication between services. They also plan to review automatic scaling settings, load balancer capacity monitoring, and VS Code's retry behavior. They will also work to reduce dependencies between critical systems to make it less likely for failures in one area to spread across GitHub. Furthermore, they will strengthen testing, secure deployment, monitoring, and alerting, recognizing that traditional operational methods have not kept pace with the speed and complexity of system changes.
GitHub's Chief Technology Officer (CTO), Vladimir Fedorov, explained that while the rapid increase in usage explains the load on the system, it is not an excuse for outages. He stated that GitHub will continue to expand the platform and improve its reliability to regain the trust of its users.
Related Posts:
in Web Service, Posted by log1d_ts