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

GitHub's August 2026 availability report confirms a rough month. On August 6, a routine deployment to an internal Actions service kicked off a roughly 9-hour outage that hit at least 74 organizations, affecting GitHub-hosted runners, Copilot coding agent, GitHub Pages builds, and Dependabot. At the same time, the platform hit meaningful milestones in its ongoing move to Azure, running its first production MySQL primary from Azure on August 11 and pushing Azure read traffic past 60% for migrated services.

What happened

Data point	Detail
Outage date	August 6, 15:22 UTC
Duration	Approximately 9 hours (incident window 10 hours 42 minutes)
Organizations affected	At least 74
Services impacted	GitHub Actions (hosted and self-hosted), Copilot coding agent, Copilot code review, GitHub Pages builds, Dependabot, repository migrations
First MySQL primary in Azure	August 11
Additional Azure primaries	Two more on August 27
Azure reads (migrated services)	Peaked at 60.4%
Azure reads (monolith)	Peaked at 64.3%
Git reads from Azure	54%
Queries removed from mysql1	Approximately 1 million per second
Additional queries removed	120,000 per second via query hygiene changes
Database work eliminated	Approximately 59,000 seconds per hour
Actions jobs rerouted	33% moved to spare capacity
Actions peak cache CPU before	98%
Actions peak cache CPU after	80%
Estimated headroom gained	3 months

What caused the August 6 outage

The incident started with a deployment to an internal service that converts incoming events into Actions jobs. The deployment content was not the problem. GitHub confirms it rolled back the deployment to verify this. The problem was that replacing pods during the rollout briefly cut capacity in one data center, pushing traffic onto the remaining sites and exhausting their headroom.

Service mesh sidecars (the networking proxies that handle traffic between pods) hit CPU throttling and ran out of memory, which cascaded into cache, DNS, and API errors across multiple clusters. A latent bug in the job-assignment path then slowed recovery: runners were handed jobs that had already been revoked, got stuck retrying them, and created a growing backlog instead of picking up new work. Most workflow runs that failed during the incident succeeded on the first re-run attempt after it ended.

Why it matters

GitHub Actions is deeply embedded in modern software delivery. An outage does not just inconvenience developers; it stops deployments, blocks code reviews, and can halt automated security checks like Dependabot. The fact that Copilot coding agent also went down during this incident is a reminder that AI-assisted coding tools sit on top of the same fragile infrastructure as everything else.

The pattern GitHub describes, running services close to capacity with little margin for routine maintenance events, is a classic reliability problem. Deployments happen constantly. If a service cannot absorb the temporary capacity dip that comes with a rolling update, any deployment becomes a potential incident. According to GitHub, the August outage reinforced the need for durable capacity and isolation work, which is still ongoing.

For teams whose CI/CD pipelines or web development workflows depend heavily on Actions, this is worth noting: GitHub’s own assessment is that it cannot fully eliminate this risk while migration work is in progress.

What GitHub is doing about it

The Azure migration is the central thread. Running MySQL primaries in Azure is a significant step because write traffic to a database primary is the most sensitive part of the stack. GitHub reports no customer impact during the August 11 or August 27 transitions, which is a good sign. More primaries are scheduled, increasing in complexity with each round.

On the Actions side, rerouting 33% of jobs to spare capacity brought peak cache CPU from 98% down to 80%. GitHub describes this explicitly as a short-term containment measure, not a permanent fix. The monitoring and detection work is also notable: pull request monitoring now tracks merge, review, and comment failures independently, so high read volume cannot mask a failing write path. Automated incident detection started combining customer support signals with service telemetry on August 21.

The load-shedding protections at the edge (rate-limiting and traffic-dropping mechanisms that activate under unexpected load) were actually used during the August incidents, which means they are operational rather than theoretical. The 95th-percentile Git request duration improved by 24% and maximum delay dropped by 78% as a result of overload protection improvements, while serving 6.4% more traffic overall.

Our take

GitHub is being unusually candid here. Admitting that a rollback confirmed the deployment content was not the problem, and that a latent bug in job assignment made recovery worse, is the kind of detail most companies scrub from public post-mortems. That is useful. It tells you this was a systems design failure compounded by insufficient capacity margins, not a one-off mistake that is now fixed.

The Azure migration progress is real and measurable, but GitHub is also being careful to flag that the migration itself is a source of risk during the transition. For businesses running critical automation through Actions, the honest read is: things are getting better structurally, but you are in the messy middle. If you have not already built retry logic and alerting into your CI/CD workflows, now is the time.

If your business relies on automated deployments or workflow automation that touches GitHub, build in failure notifications and manual fallback steps. Do not assume a queued job is running.

What to do about it

1. Add failure and timeout alerts to every critical Actions workflow so a stuck queue does not go unnoticed for hours.
2. Review which workflows are truly blocking (deployments, security scans) versus nice-to-have, and prioritize re-run strategies for the blocking ones.
3. If you use Copilot coding agent in your development process, account for its dependency on Actions availability when planning time-sensitive work.
4. Watch GitHub’s monthly availability reports. The next few months will show whether the Azure primary migrations continue without incident as complexity increases.

GitHub’s guiding principle for this period, stated in the report: availability first, then capacity, then features.

Source: GitHub Blog