Not every GitHub Actions outage is out of your control

"This is no longer a place for serious work if it just blocks you out for hours per day, every day."

Mitchell Hashimoto wrote that in April 2026, on a day that he couldn’t do any PR review for almost 2 hours because GitHub Actions was down. Again.

In the same blog post, he announced that Ghostty, the terminal emulator project he maintains, was leaving GitHub. This wasn’t a split-second decision, based on one outage. In the month leading up to the post, the HashiCorp co-founder had been keeping a journal, marking an X next to every date when a GitHub outage interfered with his work. In his own words: “Almost every day has an X.”

GitHub's own status history corroborates this. Tallies in The Register showed 26 incidents in April, 23 each in both May and June, 26 in July, and 23 in August before the month was over. August finished on 27, according to GitHub’s status history. In fact, from January to August, GitHub didn’t have a single month with fewer than 23 incidents. 23 incidents is a good month for GitHub in 2026!

September was quieter, at 14 incidents, but it still had a major one: on the 13th, a runaway data-cleanup job degraded around 28 services for two hours, including Issues, Pull Requests, Actions, and Pages, on top of a run of Copilot model disruptions in the same week. October went straight back up, with 25 incidents by the 29th, and about half of them involved Actions.

Why 2026 became the worst year for GitHub reliability

GitHub's postmortems point to the same root cause again and again: growth outpacing capacity. 

In April, GitHub's CTO said the company had originally planned for 10 times its existing infrastructure and later realized it needed 30 times that. Copilot is the biggest reason why. During the August 17 outage, a bug in Microsoft's Visual Studio Code sent 10 times the normal traffic and requests to GitHub's Copilot Token Service jumped from roughly 7,000–9,000 per second to 70,000–100,000. That surge helped keep GitHub down for nearly 8 hours. The website, the API, Actions, webhooks, Issues, Pull Requests, and Copilot itself all degraded at once, with around 1 in 5 page loads and API calls failing at the peak.

But AI coding tools didn’t break GitHub on their own. What they did was put pressure on a system that already had very little slack left, and 2026 is the year that slack ran out.

Where GitHub Actions outages actually land

Not every incident hits the same layer. Some take down GitHub’s control plane, the part that handles authentication, webhooks, and the website itself. Some hit the Actions service, the systems that assign jobs and connect runners, which every runner depends on, whoever owns the machine. And some only hit the execution layer: by default that’s GitHub’s Hosted runners, the machines that actually run your jobs.

Look through GitHub’s incident list from July to October and all three show up, again and again:

• July 8 (control plane): a bad configuration value broke service discovery for data-resident Enterprise Cloud customers, taking down the web UI, API, Git and Actions for nearly 8 hours (report)
• July 9 (execution layer): an overloaded provisioning shard left some jobs unable to get a hosted runner for more than 9 hours (report)
• July 19 (Actions service): an expired SSL certificate disrupted connectivity for self-hosted and larger runners for about 5 hours (report)
• July 25 (Actions service): a Redis configuration change left Actions’ job-assignment state out of sync across regions, for close to an hour (report)
• August 6 (Actions service): a routine deployment cut capacity and failures cascaded across hosted and self-hosted runners for more than 10 hours (report)
• August 17 (control plane): when login broke, everything downstream of it broke too, for more than 7 hours (report)
• August 26 (Actions service): the service that assigns jobs to runners stalled for almost 3 hours (report)
• September 13 (control plane): a runaway cleanup job degraded around 28 services for two hours, including token issuance for Actions workflows (status)
• September 14 (execution layer): a provisioning bug slowed new runner creation, so larger-runner jobs were slow to start for almost 3 hours (status)
• October 1 (execution layer): a routing change at GitHub’s cloud provider disrupted provisioning for GitHub-hosted runners for more than 3 hours (status)
• October 5 (execution layer): 47% of workflow runs on GitHub-hosted runners failed at the worst point of a 4-hour incident. Self-hosted runners weren’t affected (status)
• October 7 (control plane): two short write outages made up to 19% of Actions workflow runs fail with infrastructure errors (status)
• October 12 (control plane): an expensive database query caused errors across Issues, Pull Requests, Projects and Actions (status)
• October 19 (Actions service): an overloaded network link delayed logs, status updates and about 5% of hosted-runner job starts (status)

Add the queue-time and memory-crash complaints that turn up throughout GitHub’s monthly reports, and the hosted runner fleet stands out as a failure point of its own. It’s also the only layer on this list you can actually swap out.

The part of GitHub Actions you can swap out

GitHub Actions is two things bundled together: the orchestration layer (your YAML, triggers, secrets, etc.) and the execution layer (the actual machine that checks out your code, runs your build, and reports back). The control plane and Actions service from the last section both sit on GitHub’s side of that line. The hosted runners are the execution layer.

Bitrise Build Hub replaces the execution layer. You keep GitHub Actions as your CI/CD tool, and there are no workflow rewrites involved. Build Hub's setup guide covers the full switch in about 20 minutes. TL;DR: it’s basically changing the runs-on label.

But how does Bitrise Build Hub actually stack up in terms of reliability?

Build Hub runs on dedicated capacity with a publicly tracked 99.9% uptime SLA, not a shared pool that queues at peak. GitHub caps concurrent macOS jobs at 5 on Free, Pro and Team plans and 50 on Enterprise. That cap is shared between standard and larger runners, so paying for bigger Macs doesn’t raise it, and going higher means opening a support ticket. 

Build Hub scales by committed vCPU instead, and on custom Enterprise plans lets you burst above it when a release day needs more than usual. Every job runs on a freshly provisioned, single-use VM, so one bad job can't leave state behind for the next one to inherit (the failure mode ForeFlight engineers described dealing with on their old self-hosted Mac Minis).

Execution-layer outages like October 5 are exactly what this protects you from: while 47% of workflow runs on GitHub-hosted runners were failing, self-hosted runners weren’t affected, and Build Hub runners connect to GitHub the same way. And because Bitrise ships new Xcode versions within 24 hours of Apple's release, waiting for tooling stops being its own kind of outage.

What Bitrise Build Hub doesn’t fix

Moving your builds off GitHub’s runners doesn’t protect you from problems on GitHub’s side of the line. Your workflows still trigger through GitHub, so if authentication or webhook delivery breaks platform-wide the way it did on August 17, your job may never get the signal to start, no matter whose machine would have run it. And because Build Hub runners connect to GitHub the same way self-hosted runners do, Actions service outages like July 19 and August 26 hit them too. But it does fix the failure modes specific to GitHub’s hosted runners: not enough runner capacity, not enough headroom, and provisioning systems buckling under the load. If you need a replacement for GitHub Actions, we have Bitrise CI. 

What to check when analyzing GitHub Actions downtime

Pull your own team's incident history and sort it into the three layers above. If most of your pain came from queued jobs, memory crashes on GitHub's Mac runners, or waiting weeks for a new Xcode version to land, that's the execution layer. That’s the part you can replace today. If your pain came from GitHub being unreachable altogether, obviously you can’t solve that with a runner swap.

If you are considering a runner swap, we’ve done a breakdown of the best alternative runners for GitHub Actions (plus some pricing traps to avoid).

Our Build Hub vs GitHub-hosted runners comparison page shows how we stack up directly against GitHub Actions. Not just on reliability, but build speeds, hardware specs, caching, security, and pricing.

You can also check our uptime % and incident history over at status.bitrise.io.

FAQ

What caused GitHub's 2026 outages?
Mostly capacity. GitHub CTO Vlad Fedorov wrote in April that the company began executing a plan to increase capacity 10 times over back in October 2025, then concluded by February that it needed to design for 30 times today's scale instead. Copilot and other AI coding tools are the biggest driver of that demand curve, and several of the year's worst incidents, including August 17, trace back to that same gap between planned and actual capacity.

What happened during GitHub's August 17 outage?
Network saturation at a Central US data center overwhelmed GitHub's authentication infrastructure, and an auto-scaling feature that should have absorbed the load failed to kick in. A bug in Microsoft's Visual Studio Code made it worse by sending 10 times the normal traffic to the Copilot Token Service. The result was about 7 hours of degraded website, API, Actions, webhooks, Issues, Pull Requests, and Copilot service, with roughly 1 in 5 page loads and API calls failing at the peak.

Is GitHub down right now?
This article looks at the pattern behind 2026's outages rather than real-time status. For that, GitHub's own status page and Downdetector's GitHub tracker are the best sources.

Which GitHub Actions outages can Bitrise Build Hub prevent? 

Execution-layer outages: the ones where GitHub’s hosted runners fail, run out of capacity, or can’t be provisioned. On October 5, for example, 47% of workflow runs on GitHub-hosted runners failed at the worst point, while self-hosted runners, which is how Build Hub runners connect to GitHub, weren’t affected.

Why do teams use self-hosted runners with GitHub Actions?
Usually it comes down to specs or cost. GitHub’s own hosted runners are capped and comparatively low-spec, 4 vCPU and 14GB RAM on Intel Mac, for instance. Even GitHub’s paid larger M2 runners top out at 5 vCPU and 14GB RAM, and they count toward the same macOS concurrency cap. Some teams also need custom hardware or software GitHub doesn’t support, or have outgrown per-minute pricing at high build volume. The trade-off, as ForeFlight found running their own Mac Minis, is that self-hosting turns your platform team into hardware administrators. Bitrise Build Hub exists for teams who want the benefits of moving off GitHub’s default runners without taking on that maintenance burden themselves.

Does Bitrise Build Hub replace GitHub Actions?
No. Build Hub plugs into GitHub Actions as the execution layer underneath it. GitHub still handles triggers and secrets. Only the runs-on label changes.

Will Bitrise Build Hub protect my team from every GitHub outage?
No. Build Hub removes exposure to execution-layer issues: runner capacity, provisioning, and Xcode lag. It doesn’t protect against a GitHub control-plane outage that stops workflows from triggering in the first place, or an Actions service outage that hits every runner, self-hosted ones included.