GitHub July 2026 Availability Report: Actions Outage and Azure Migration Progress

GitHub's July 2026 availability report, published in August, opens with an acknowledgment that the GitHub Actions outage on August 6 was unacceptable in both impact and duration. The full root cause analysis is still in progress and will appear in a September post covering August. For July itself, the headline number is that more than half of monolith read traffic now runs in Azure Central US, and GitHub says it has a clear path to moving all production traffic out of its own datacenters by the end of calendar year 2026.

What happened

Metric	Detail
Azure read traffic peak (July 28)	52.75% of monolith read traffic
Git traffic in Azure	47% (up from 43% in June)
Repos with a second replica in Central US	29%
Auth queries offloaded at peak	More than 1 million per second
Major authorization lookup on isolated path	80%
Pull request service parity for authenticated reads	99.87%
Auth service load reduction from caching	18.2%
Artifacts table query time	Cut in half by one production change
July 8 incident duration	7 hours 4 minutes (15:07 to 22:13 UTC)
Full datacenter exit target	End of calendar year 2026

The August 6 Actions outage is the main reason this report leads with an apology rather than a milestone. GitHub has not yet published the full root cause analysis, but the report offers one important structural detail: the “launch service,” the component that connects GitHub’s core application to the Actions runner infrastructure, was still running inside GitHub’s own datacenters rather than on Azure. Because this component is largely asynchronous and can queue work during problems, migrating it had not been treated as urgent. When cascading failures hit, that architectural choice meant recovery took far longer than it should have.

GitHub says it is now accelerating the move of GitHub Actions to Azure specifically to gain the headroom and spike-absorption capacity that its own datacenters cannot match. Complete details will appear in the September post covering August incidents.

What changed in July

Aside from the Actions situation, July marked real progress on the broader Azure migration. The key milestone: July 28 was the first day GitHub consistently kept more than half of monolith read traffic running in Azure Central US, with a peak of 52.75%. Git operations followed a similar curve, reaching 47% in Azure versus 43% the month before.

Two other changes reduced the blast radius of any single failure:

• The first authentication tables moved off GitHub’s oldest shared database onto dedicated infrastructure. At peak, the dedicated user service offloads more than one million queries per second from that shared path.
• Repository content traffic now runs entirely from Central US on dedicated infrastructure, and the pull request service reached 99.87% parity with the main application for authenticated reads.

Search workloads also moved fully to Central US, giving that service extra headroom during demand spikes. One code-level change cut total query time on the artifacts table in half. Caching added to the Git authorization path reduced load on the authorization service by 18.2%, even as request volume grew.

GitHub also embedded the stability validation process introduced after May’s incident into every major traffic expansion going forward. That process pauses and validates before pushing more traffic to new infrastructure, trading speed for confidence.

What comes next

GitHub has published specific targets for the current quarter:

• 70% of read traffic in Azure Central US
• 30% of write traffic in Azure Central US
• Every production service brought online in Central US
• A second Azure region added to support regional resilience

Write traffic cannot follow read traffic until database primaries move to Azure. That step is the next major unlock. After that, a second Azure region provides the foundation for true regional failover: the ability to survive the complete loss of one region without a customer-facing outage.

The report closes with the phrase GitHub has been using to describe its priorities in order: availability, then capacity, then features.

Why it matters

GitHub Actions is core infrastructure for most development teams. If your CI/CD pipeline runs on Actions, an outage like August 6 stops deployments cold. The architectural detail in this report is worth paying attention to: the problem was not a bug in Actions itself, but a “bridge” component that was deprioritized for migration because it seemed low-risk. That is a common pattern in infrastructure work and a reminder that async queuing is not the same as fault tolerance.

For teams that rely on GitHub for anything beyond version control, including web development pipelines, package hosting, Copilot, and API access, the July 8 incident (7 hours 4 minutes of degraded service across the Web UI, REST API, GraphQL API, Actions, Packages, Copilot, and Git operations) is the more immediately relevant data point. Eight incident write-ups are included in the full report.

The migration trajectory also matters for anyone evaluating GitHub’s long-term reliability. Moving from a single owned datacenter to multi-region Azure with isolated services is the right architectural direction. But the August 6 outage shows how much risk remains while the migration is mid-flight.

Our take

GitHub’s reporting is unusually transparent for a platform of this size, and that transparency is genuinely useful. The specific numbers (52.75%, 18.2%, 99.87%) signal that engineering teams are measuring the right things and publishing them without rounding to feel-good figures.

That said, the August 6 outage is a problem that honesty alone does not fix. The root cause analysis is not finished, and the full account will not appear until September. For any team with zero tolerance for CI/CD downtime, “we’re accelerating the migration” is not a service level agreement. It is worth having a fallback build path or at least a documented manual deployment procedure, even if you never use it.

We cover GitHub Enterprise Server updates separately for teams running air-gapped environments, where this Azure migration does not apply but similar resilience questions still do. If you are thinking about how outages like this affect your own automation stack, our workflow automation work often surfaces exactly these single points of failure.

The end-of-2026 datacenter exit target is credible given July’s numbers, but it depends on database primary migrations going smoothly. That is historically where these projects slow down. Watch the Q3 report closely.

What to do about it

1. Check whether your CI/CD pipeline has a documented fallback if GitHub Actions is unavailable for several hours.
2. Review which GitHub services your deployments depend on beyond Actions: Packages, the REST API, and Copilot all degraded during the July 8 incident.
3. Subscribe to the GitHub Status page and set up alerts so your team knows within minutes, not hours, when a degradation starts.
4. Read the August report when it publishes in September for the full Actions root cause analysis before making any architectural decisions based on the partial picture available now.

Source: GitHub Blog