Another GitHub Actions Outage, and the Ninth in a Month

GitHub Actions fell over again this afternoon. The incident opened at 15:22 UTC on August 6 as "degraded performance," escalated to a critical outage within the hour, and as of GitHub's 17:40 UTC update workflow runs were still failing or stalling, queued jobs were timing out, and the Actions API was returning errors — with some customers hitting unexpected rate limits on top. GitHub Pages went down alongside it (opened 15:03 UTC, resolved by 16:22), and the blast radius pulled in hosted runners, webhook deliveries, Copilot code review, and the Copilot coding agent.

One outage is weather. The reason this one matters is the climate: GitHub's own public incident feed lists nine Actions-related incidents since July 7 — "delays starting Actions runs," "Actions runs are experiencing failures to start," "Actions run failures and delays," and so on — four of them flagged critical. The status page currently pegs Actions' recent uptime at 99.7%. That sounds fine until you do the arithmetic: it's roughly two hours of downtime a month, and it sits below the 99.9% quarterly commitment GitHub makes to Enterprise Cloud customers. The Hacker News thread on today's incident filled up with people who couldn't merge PRs for over an hour, which is exactly what you'd predict.

Actions isn't CI anymore. It's the control plane.

The instinctive read — "CI is down, go get coffee" — undersells what an Actions outage now means, because GitHub has spent four years routing everything through it.

Pages is the obvious example. Since GitHub made Actions the default build path for all Pages sites, a Pages deploy is an Actions workflow, which is why the two services fail together — today wasn't a coincidence, it's architecture. Required status checks mean an Actions outage freezes every protected branch in your org. Merge queues stall because the queue advances on green checks. And the newer surface area — Copilot code review, the Copilot coding agent — turns out to ride the same rails, per GitHub's own incident updates. What used to be a CI vendor hiccup is now a platform-wide write freeze.

The part that surprises teams mid-incident: self-hosted runners don't save you. Your runner is just a poller; it asks GitHub's service for work. When the failure is in job scheduling or the Actions API — as it was today — jobs never get assigned, and your fleet of carefully maintained machines sits idle while the status page glows red. Self-hosting the compute without self-hosting the control plane buys you capacity independence, not availability independence. Developers in the thread reported the confusing symptom that results: "The job was not acquired by Runner of type hosted even after multiple attempts," which reads like your misconfiguration, not their outage.

The elephant: GitHub is mid-migration

GitHub hasn't published root causes for this cluster of incidents yet, so honest caveat: nobody outside the company can prove they're connected. But the timing deserves scrutiny. GitHub is currently executing a full migration off its own Virginia data centers onto Azure — reported by The New Stack and others last fall as an 18-to-24-month effort that leadership explicitly prioritized over feature development, with CTO Vladimir Fedorov telling employees that meeting Copilot's capacity demands was "existential." This is also GitHub's first year without its own CEO, folded into Microsoft's CoreAI organization after Thomas Dohmke's departure in August 2025.

Anyone who's done a live infrastructure migration at scale knows the shape of this: reliability degrades mid-flight, when systems straddle two environments and every incident has twice the suspects. GitLab's cloud migration in 2018 went through the same trough. If that's what's happening here, the uncomfortable implication is that this doesn't get better next month. The migration reportedly has a year-plus to run.

What to actually do about it

The wrong response is panic-migrating your CI. The right response is treating Actions like any other third-party dependency with an observed SLO of about 99.7% and designing your escape hatches now, while nothing is on fire.

Set up break-glass merges before you need them. Repo admins can bypass branch protection with gh pr merge --admin via the gh CLI, and rulesets support explicit bypass lists. Decide today who's on that list and when it's acceptable to use — negotiating that in an incident channel while releases slip is the worst-case version.

Decouple deploys from Actions. If your production deploy has exactly one path and that path is a workflow run, you've inherited GitHub's availability as your deploy availability. Keep a runbook for building and pushing from a trusted machine. For business-critical static sites, remember Pages is Actions underneath; hosts like Cloudflare Pages or Netlify pull from the repo through a separate build pipeline.

Check the status feed before you debug. Incident-time errors are misleading — internal server errors and "runner did not acquire job" messages look local. Subscribe to githubstatus.com's RSS or webhook and pipe it into the channel where CI alarms land. An hour of engineers bisecting their own workflow files during a platform outage is pure waste.

Do the mirror-CI math honestly. A second system on Buildkite or a self-hosted control plane doubles maintenance surface, splinters caching, and forks your workflow definitions. For most teams, that costs more than two hours a month of frozen merges. But if you have contractual release windows or an on-call rotation that ships fixes through CI, a minimal mirror for the release-critical path stops being paranoia and starts being insurance.

The bigger judgement: Actions won by being the path of least resistance, and it's still a reasonable default. But GitHub has concentrated an enormous amount of the industry's delivery pipeline on a single control plane at precisely the moment that control plane is being forklifted onto new infrastructure. For the next year or so, the run rate we can all see in the incident feed — not the SLA on the pricing page — is the number to plan around.