GitHub has had a rough few months.
Nine incidents in May. Six in June. Eight in July. Then a string of August problems affecting Actions, pull requests, APIs, authentication, Copilot, and raw repository downloads.
It is tempting to call this “GitHub going down more often.”
That is true from a developer’s point of view. But the more useful question is: why are failures in different parts of GitHub showing up at the same time?
GitHub’s own incident reports point to three connected problems.
1. GitHub is changing the plane while flying it
GitHub is in the middle of a major infrastructure migration. It is moving more traffic and critical services from older shared data centers into Azure.
That is the right long-term direction. Shared infrastructure creates a huge blast radius. GitHub says more than half of its monolith read traffic now runs in Azure Central US, and it is splitting authentication, authorization, repository content, and pull request workloads into more isolated services.
But migrations create risk before they create resilience.
Old systems, new systems, partial failover paths, data replication, service discovery, and traffic routing all have to work together during the transition. A failure in one layer can still reach many customer-facing services.
That is what happened on July 19. A database-connectivity problem resulted in incomplete data for GitHub’s DNS control plane. Automated DNS reconfiguration treated that incomplete data as valid, changing DNS behavior across the fleet. As cached records expired, internal services could no longer resolve one another. Webhooks, Actions, Copilot, and GitHub.com were all affected.
The lesson is not that DNS is fragile. It is that automation without safe defaults can turn incomplete information into a fleet-wide change.
2. Small configuration mistakes are reaching very large blast radiuses
Several recent incidents began with routine changes.
On August 6, a deployment to an internal GitHub Actions service exposed an existing capacity and concurrency weakness. As pods were replaced, remaining capacity saturated. Services crashed, the impact cascaded across clusters, and at peak 71% of workflow runs had infrastructure failures.
On August 12, a database migration removed two indexes while application settings still referenced them. Pull requests, issues, and search started returning errors.
On August 17, a misconfigured autoscaling policy watched the host service but not its Istio sidecar’s concurrency limit. The sidecar hit its limit, load balancers saturated, and an authentication path became slow or unavailable. Then retry behavior made it worse. Copilot token traffic rose from a normal 7,000 to 9,000 requests per second to 70,000 to 100,000 requests per second.
This is the modern outage pattern.
The first failure is often manageable. Retries, shared dependencies, and recovery behavior turn it into an incident.
3. GitHub is no longer just a source-code host
A GitHub outage used to mean developers could not push or open a pull request.
Now it can stop CI/CD pipelines, delay deployments, break webhooks, interrupt release downloads, block authentication, affect developer agents, and slow down Copilot. GitHub has become a control plane for software delivery.
That makes even partial failures feel much bigger.
A 2% error rate in one internal service might have been invisible ten years ago. Today, it can stop a deployment pipeline, delay a production fix, or prevent an engineering organization from responding to an incident.
That is why the recent outages feel different. The dependency graph around GitHub has become much larger.
The real takeaway
GitHub’s problem is not one bad team or one bad change.
It is the difficult middle of a platform transformation: decomposing shared systems, adding capacity, moving traffic, supporting AI workloads, and preserving reliability for millions of developers at the same time.
The good news is that GitHub’s public reports are unusually specific. They are naming configuration mistakes, capacity limits, retry storms, unsafe automation, and shared dependencies.
The harder question is whether the architectural changes will arrive before the next concentrated run of failures.
For engineering leaders, the lesson is simple:
Reliability is not proven when a change works in isolation. It is proven when the system remains stable under retries, partial failure, traffic shifts, and recovery load.
Sources