GitHub’s incidents rose from 2 to 8 a month as it moved 140 of 151 services to Azure

01Eight write-ups in October, after two

Until July, each report opened with one sentence: in that month, “we experienced N incidents that resulted in degraded performance across GitHub services”. From August the reports drop that sentence and write up each incident at length: what customers saw, what went wrong, and what GitHub is changing.³⁵ Over the twenty months to October the count ran from 1 to 10 a month: 29 in the ten months to December 2025, and 60 in the ten months of 2026, with the highest month in April.⁵

More incidents did not mean longer ones. On the status page, October’s eight ran for 16 hours 43 minutes in all; August’s five ran for 33 hours 9 minutes, led by an Actions outage of 10 hours 42 minutes on 6 August. Nor is the status page’s own total at a high: February logged 37.³⁶

02What the move to Azure is, and where it showed

GitHub explained the programme in its May report: its traffic is “growing rapidly, driven in large part by AI-assisted and agentic development workflows”, and keeping up means “moving to Azure for elastic capacity, breaking our monolith apart into isolated services, and eliminating the shared failure points that have driven past incidents”. In February 8% of the main application’s traffic was served from Azure; by 9 November Azure served 66% of its reads and 52% of Git reads. Traffic on the services already moved has risen 82% since March.⁴¹

Two of October’s eight incidents began in network connections to the cloud. On 5 October a partial network failure at the cloud provider disrupted connections to the cloud-hosted databases behind the service that assigns Actions jobs, and for about 90 minutes most jobs on GitHub-hosted runners did not start within five minutes; self-hosted runners were not affected. On 19 October an Actions service’s retries to its cache servers saturated the network link between GitHub’s data centre and a cloud region. GitHub also reports an Azure network disruption on 29 October across all three Central US availability zones, affecting at least 34,128 signed-in users, which is not among the eight.¹

The rest had other causes: two write outages on 7 October, when a newly added machine routed database writes to retired servers (web and API failures peaked at 8.9% and 9.3%, at more than 12,000 and 11,000 organisations); an overloaded event-streaming platform on 21 October; a Copilot credential with an outside model provider that stopped working on 28 October; and a full database connection pool on 30 October, when 43% of merge attempts failed.¹

GitHub’s account of 9 November is specific. After the database moved, “the volume of requests exceeded the capacity and rate limits configured there”; it shifted some traffic back, raised the limits and moved it again in steps. It says the migration of that cluster is complete, and that it will shift traffic in smaller steps in the moves still to come.⁷ The next day, a recent change to how merges are computed overloaded the systems behind Git operations; GitHub turned that change off and briefly limited low-priority traffic, which restricted commit pages for users who were not signed in.⁸ On 13 November merges timed out for about 3% of requests before GitHub took mitigating action.¹²

03What to check after an incident, and what to watch

The incident records name the work a team may have to redo. On 9 November, GitHub says, “Actions skips events older than 30 minutes, so some workflow runs did not start” when webhook deliveries ran late, and runs left stuck after the evening incident held concurrency until released; GitHub is preparing an API for customers to clear them. On 10 November 0.09% of pull-request events started no workflow and had to be triggered again.⁹⁷⁸

The status page now shows each service’s uptime over 90 days. A major outage counts in full, a partial outage at 30% of its duration, and degraded performance not at all, so a month of many degraded incidents can leave the uptime figure unchanged.¹⁰

What to watch.

• A second Azure region. GitHub says the East US 3 build is about a week behind plan, with its first traffic ramp in the first week of December.¹
• The last 11 services and 18 database primaries still to move, after the lesson of 9 November about limits in the new region.¹⁷
• The November report. Each of the last six appeared between the 8th and the 14th of the next month. November already has three critical incidents in thirteen days, and 11 November’s cause is still to be published.⁶¹¹

Other providers’ failures the same week, read from their own status posts: Microsoft 365’s outage of more than 21 hours and AWS’s 5 hours 45 minutes of failed launches in Tokyo.