GitHub Reports Eight Incidents Affecting Service Performance in October 2026
GitHub continues to provide monthly updates on its availability and reliability efforts.
Summary of October: The company added significant independently scalable Azure capacity and mitigated several failure escalation paths. However, challenges such as write outages, monitoring gaps during data migrations, and a regional network disruption underscored the need for improved operational safety and capacity growth.
As of November 9, 140 of 151 production services and 32 of 50 MySQL primaries were operational in Azure Central US. Azure handled 63% of migrated-service reads, 66% of monolith reads, and 52% of Git reads. A compute expansion across all nine Central US Kubernetes clusters more than doubled capacity.
This increased capacity is already supporting real growth. Traffic for migrated services surged by 82% since March, with Central US absorbing loads beyond previous weekly averages from the original datacenter, allowing GitHub to grow without overextending its initial environment.
Targeted reliability improvements were also implemented. Changes to GitHub Actions increased capacity for critical Azure control-plane requests, while a separate NAT-gateway mitigation reduced usage by 85%. During this change, only four production jobs failed, compared to approximately 800 expected without the mitigation.
Additionally, GitHub addressed concentrated sources of database load. A high-traffic GitHub Actions endpoint, which handled over 250 million requests daily, transitioned to a more efficient service path, reducing peak database reads by 85%. The requirement for at least three characters before searching repository topics decreased slow or terminated queries for that pattern by around 98%.
Despite these efforts, reliability remained a concern. The October 7 write outages revealed an unsafe interaction between database orchestration and production routing. An Azure network disruption on October 29 impacted all three Central US availability zones, affecting at least 34,128 signed-in users.
The East US 3 buildout is currently about one week behind schedule, with the next phase set to begin its first validated traffic ramp in the first week of December. Efforts to enhance migration safety, dependency isolation, and regional recovery are ongoing.
The guiding principle remains: availability, then capacity, then features.
October 05 19:11 UTC (lasting 3 hours and 38 minutes)
Duration: approximately 3 hours and 45 minutes.
Customers may have noticed delays in GitHub Actions jobs on GitHub-hosted runners, with some workflow runs failing to start. During the peak period, most jobs did not start within five minutes. The situation improved as the company failed over to healthy regions and added capacity.
What went wrong and why?
Actions jobs remained queued or failed to start due to a reliability issue with the service that assigns jobs to GitHub-hosted runners. A partial networking failure on the cloud provider’s side disrupted connections between one datacenter region and the cloud-hosted databases that the service relies on.
How did we respond?
- Alerts flagged errors and slow job assignments, prompting the declaration of an incident.
- The service that assigns jobs to GitHub-hosted runners was redeployed, but it did not recover.
- We failed over the affected databases and storage to healthy regions, one service at a time, and added capacity.
- Collaboration with the cloud provider resolved the networking failure, allowing remaining services to recover.
How are we making incidents like this less likely or less impactful?
- The service that assigns jobs to GitHub-hosted runners is being improved to better handle sudden increases in load.
- Prioritization of runner assignment based on customer profile has been expanded when available capacity is degraded.
October 06 19:57 UTC (lasting 3 hours and 43 minutes)
Duration: approximately 6 minutes of failed or slow requests across github.com, followed by approximately 3 hours and 30 minutes during which enterprise migrations were paused.
What went wrong and why?
A surge in migration activity caused GitHub Enterprise Importer to send large queries to a shared database, which took longer than usual to process, exhausting the database’s available connections.
How did we respond?
- Automated monitoring detected the failures and alerted on-call engineers.
- An incident was declared, and enterprise migrations were paused to prevent recurrence while investigating the cause.
How are we making incidents like this less likely or less impactful?
- The query sent by GitHub Enterprise Importer has been optimized to remain small and fixed in size.
- Automated importer backoff is being implemented when the database is under strain.
October 07 15:14 and 17:17 UTC (lasting 1 hour and 11 minutes, and 47 minutes, respectively)
Duration: two separate write outages lasted approximately 10 minutes and 9 minutes, totaling about 19 minutes.
What went wrong and why?
During routine maintenance, machines managing database write routing were replaced. One new machine started with outdated records, leading to incorrect routing settings.
How did we respond?
- Automated monitoring alerted us to failing writes, prompting an incident declaration.
- Writes recovered when a machine with correct records became leader.
How are we making incidents like this less likely or less impactful?
- Improvements have been made to how database servers are retired to prevent outdated records from remaining.
October 19 15:49 UTC (lasting 1 hour and 7 minutes)
Duration: approximately 1 hour and 7 minutes.
Details on this incident will be provided in future reports.
Source: GitHub Blog